#45167 [Asn]: timezones returned by datetime objects are not accepted by other functions

From: Date: Wed, 04 Jun 2008 12:24:35 +0000
Subject: #45167 [Asn]: timezones returned by datetime objects are not accepted by other functions
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-125490@lists.php.net to get a copy of this message
ID: 45167 User updated by: peter dot bex at solide-ict dot nl Reported By: peter dot bex at solide-ict dot nl Status: Assigned Bug Type: Date/time related Operating System: NetBSD/amd64 PHP Version: 5.2.6 Assigned To: derick New Comment: What this means is that there is absolutely no reliable way to use strftime on a datetime object with a timezone like that. I've created a feature request (45173) for a strftime method on the datetime class. Previous Comments: ------------------------------------------------------------------------ [2008-06-04 12:07:35] derick@php.net Type 1 = UTC offset (+02:00) Type 2 = Timezone Abbreviation (CEST, PDT) Type 3 = Timezone Identifier (Europe/Oslo) You can see this back in the output of date_parse() for example. ------------------------------------------------------------------------ [2008-06-04 12:01:46] peter dot bex at solide-ict dot nl So what's type 3 then? (and what are types 1 and 2?) ------------------------------------------------------------------------ [2008-06-04 11:54:31] derick@php.net date_default_timezone_set() doesn't throw an exception because it's a procedural function. Instead, it returns false in case the $timezone_identifier is invalid. The identifier that I meant, is one of the Timezone Identifiers that are documented here: http://no2.php.net/timezones ------------------------------------------------------------------------ [2008-06-04 11:47:13] peter dot bex at solide-ict dot nl Can you elaborate a bit more? Why wasn't this intended to work and what on earth are "objects of type 3"? The "(identifiers)" note doesn't help, since identifiers are to me names for things in a programming language (like variable names or class name and such). Also, shouldn't date_default_timezone_set() throw an exception in the way that the timezone class does when you pass it an invalid timezone? Silently ignoring the timezone and doing nothing is what caused me a lot of frustration and confusion in tracking what was going wrong in my script. It took me a while before I found out that this was not working (again, it is *very* unintuitive, and IMHO it qualifies as a bug). ------------------------------------------------------------------------ [2008-06-04 10:27:21] derick@php.net Not really a bug, as it wasn't meant to do this for anything else than timezone objects of type 3 (identifiers) - but that doesn't mean we can't add it. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45167 -- Edit this bug report at http://bugs.php.net/?id=45167&edit=1

« previous php.bugs (#125490) next »