Edit report at https://bugs.php.net/bug.php?id=42842&edit=1
ID: 42842 Comment by: eclipsechasers2 at yahoo dot com Reported by: giewont at gmail dot com Summary: dst information lost over Year 2038 Status: Suspended Type: Bug Package: Date/time related Operating System: Windows NT 5.1 build 2600 PHP Version: 5.2.4 Block user comment: N Private report: N New Comment: 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). Previous Comments: ------------------------------------------------------------------------ [2007-10-23 14:02:12] 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?). ------------------------------------------------------------------------ [2007-10-20 15:04:49] der...@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-04 09:59:13] 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-04 03:41:43] judas dot iscariote at gmail dot com Please read http://en.wikipedia.org/wiki/Year_2038_problem to know the cause. ------------------------------------------------------------------------ [2007-10-03 16:01:14] 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) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=42842&edit=1
