|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #42842 dst information lost over Year 2038
Submitted: 2007-10-03 16:01 UTC Modified: 2013-06-12 19:39 UTC
Avg. Score:4.2 ± 1.0
Reproduced:4 of 4 (100.0%)
Same Version:0 (0.0%)
Same OS:2 (50.0%)
From: giewont at gmail dot com Assigned:
Status: Duplicate Package: Date/time related
PHP Version: 5.2.4 OS: Windows NT 5.1 build 2600
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: giewont at gmail dot com
New email:
PHP Version: OS:


 [2007-10-03 16:01 UTC] giewont at gmail dot com
When I create DateTime object using UTC and then switch to timezone with DST eg. 'Europe/Warsaw' and i set Year to any after 2038 the DST doesn't work.

like below: in may Warsaw is in GMT+2 time zone so when i set UTC time to 12:00:00 time in Warsaw should be 02:00:00 (14:00:00)

Reproduce code:
	$gmt = timezone_open('UTC');
	$eu = timezone_open('Europe/Warsaw');
	$date = new DateTime('2040-05-05 12:00:00', $gmt);
	echo $date->format('d-m-Y h:i:s') . '(' . $date->getTimezone()->getName() . ')<br>';
	echo $date->format('d-m-Y h:i:s') . '(' . $date->getTimezone()->getName() . ')<br>';
	$date = new DateTime('2000-05-05 12:00:00', $gmt);
	echo $date->format('d-m-Y h:i:s') . '(' . $date->getTimezone()->getName() . ')<br>';
	echo $date->format('d-m-Y h:i:s') . '(' . $date->getTimezone()->getName() . ')<br>';

Expected result:
05-05-2040 12:00:00(UTC)
05-05-2040 02:00:00(Europe/Warsaw)
05-05-2000 12:00:00(UTC)
05-05-2000 02:00:00(Europe/Warsaw)

Actual result:
05-05-2040 12:00:00(UTC)
05-05-2040 01:00:00(Europe/Warsaw)
05-05-2000 12:00:00(UTC)
05-05-2000 02:00:00(Europe/Warsaw)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-10-04 03:41 UTC] judas dot iscariote at gmail dot com
Please read

to know the cause.
 [2007-10-04 09:59 UTC] giewont at gmail dot com
OK, but Y2038 problem is not the same as daylight saving time whith doesn't work after 2038. DateTime Object is supposed to by a wrapper around 64bit int and it should work after 2038. 

And it work, because i can set dates after 2038 for example 2040, but the bug is that when i set timezone to 'Europe/Warsaw' and the date is set to summer eg. 05.May the GMT offset should be +2h not +1h.

the daylight saving time works properly to 2038, and it should work after 2038 when i use DateTime.

the Y2038 problem touches mktime but shouldnt cause any errors in DateTime
 [2007-10-20 15:04 UTC]
This is not something I can fix - the timezone database simply doesn't have the resolution to store anything outside of the signed integer range for now. Luckily they are working on extending this - if that makes it into the database, I can fix this.
 [2007-10-23 14:02 UTC] giewont at gmail dot com
OK, but what do you need to store? The dst always changes on last saturday of march and october, that's all you have to know. So please tell me what is longer than signed int and have to be stored in timezone's database to support dst change after 2038? And if you can, tell me please what is stored in this database (or tell me where can i read about it?).
 [2013-06-01 05:35 UTC] eclipsechasers2 at yahoo dot com
It seems that the timezone database now has the necessary resolution. From the man page for tzfile, "For version-2 format timezone files, the above header and data is followed by a second header and data, identical in format except that eight bytes are used for each transition time ..." I do not know when version-2 was introduced, but it is certainly in widespread use now. In particular, on my Ubuntu 64-bit system, zdump shows timezone transitions all the way through the year 2499. The version of PHP in use on that system is PHP 5.3.10-lubuntu 3.6 with Suhosin patch (cli). I am also using the latest version of timezonedb through PECL; phpinfo shows this as "Olson" Timezone Database Version 2013.3. But PHP is unaware of any timezone transitions after Jan. 17, 2038; e.g. America/Los_Angeles for 2039-06-07 shows an 8-hour difference from GMT (i.e. Pacific Standard Time) rather than 7 hours (daylight time).
 [2013-06-12 19:39 UTC]
-Status: Suspended +Status: Duplicate
 [2013-06-12 19:39 UTC]
Closed in favour of bug #64992.
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC