php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #42842 dst information lost over Year 2038
Submitted: 2007-10-03 16:01 UTC Modified: 2013-06-12 19:39 UTC
Votes:5
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 Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
11 - 5 = ?
Subscribe to this entry?

 
 [2007-10-03 16:01 UTC] giewont at gmail dot com 
Description:
------------
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:
---------------
	date_default_timezone_set('Europe/Warsaw');
	$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>';
	$date->setTimezone($eu);
	echo $date->format('d-m-Y h:i:s') . '(' . $date->getTimezone()->getName() . ')<br>';
	$date->setTimezone($gmt);
	
	$date = new DateTime('2000-05-05 12:00:00', $gmt);
	echo $date->format('d-m-Y h:i:s') . '(' . $date->getTimezone()->getName() . ')<br>';
	$date->setTimezone($eu);
	echo $date->format('d-m-Y h:i:s') . '(' . $date->getTimezone()->getName() . ')<br>';
	$date->setTimezone($gmt);

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)

Patches

Pull Requests

History

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

http://en.wikipedia.org/wiki/Year_2038_problem

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] derick@php.net 
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] aharvey@php.net
-Status: Suspended +Status: Duplicate
 [2013-06-12 19:39 UTC] aharvey@php.net 
Closed in favour of bug #64992.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Nov 01 04:00:02 2025 UTC