Edit report at https://bugs.php.net/bug.php?id=42842&edit=1
ID: 42842 Updated by: ahar...@php.net Reported by: giewont at gmail dot com Summary: dst information lost over Year 2038 -Status: Suspended +Status: Duplicate 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: Closed in favour of bug #64992. Previous Comments: ------------------------------------------------------------------------ [2013-06-01 05:35:24] 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). ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=42842 -- Edit this bug report at https://bugs.php.net/bug.php?id=42842&edit=1
