|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45167 timezones returned by datetime objects are not accepted by other functions
Submitted: 2008-06-04 10:13 UTC Modified: 2008-07-20 21:01 UTC
From: peter dot bex at solide-ict dot nl Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 5.2.6 OS: NetBSD/amd64
Private report: No CVE-ID: None
 [2008-06-04 10:13 UTC] peter dot bex at solide-ict dot nl
When creating a datetime object from a string that includes timezone offset information (like "10:00:00+02:00"), the timezone object's name can not be used for creating new timezone objects or setting the default timezone. In effect, it's an "impossible object": there's no way to recreate an object like that yourself.

This also means you would get unexpected results when using, for example, strftime(). If you use date_default_timezone_set to change the timezone to the object's timezone and print the date info, it will give you the wrong output.

Reproduce code:
echo "Before: ".date_default_timezone_get()."\n";
$foo = new datetime('10:00:00+02:00');
$name = $foo->getTimeZone()->getName();
echo "Setting timezone: $name\n";
echo "After: ".date_default_timezone_get()."\n";
echo "strftime: ".strftime('%H:%M:%S', $foo->format('U'))."\n";

$bar = new datetimezone($name);
echo "datetimezone object name: ".$bar->getName();

Expected result:
Before: UTC
Setting timezone: GMT+02
After: GMT+02
strftime: 10:00:00
datetimezone object name: GMT+02

(not sure if GMT+02 is the correct timezone name. In any case, it should be some timezone name that's accepted by other timezone-related functions/classes)

Actual result:
Before: UTC
Setting timezone: +02:00
After: UTC
strftime: 08:00:00

PHP Fatal error:  Uncaught exception 'Exception' with message 'DateTimeZone::__construct(): Unknown or bad timezone (+02:00)' in /path/to/index.php:10


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-06-04 10:27 UTC]
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.
 [2008-06-04 11:47 UTC] 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 11:54 UTC]
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:
 [2008-06-04 12:01 UTC] peter dot bex at solide-ict dot nl
So what's type 3 then? (and what are types 1 and 2?)
 [2008-06-04 12:07 UTC]
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:24 UTC] peter dot bex at solide-ict dot nl
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.
 [2008-07-20 21:01 UTC]
Marked as duplicate (bogus) for alternative bug #45543.
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Mon Feb 24 03:01:25 2020 UTC