#22635 [Csd]: 1.1.1970 <> 24 hours in [gm]mktime

ID: 22635 Updated by: vrana@php.net Reported By: jsteen at timecom dot com Status: Closed Bug Type: Documentation problem Operating System: win32 PHP Version: 4.3.1 New Comment: Unix epoch starts at 1:00 CET which is 0:00 GMT. It confused me a little :-). As 1970-01-01 00:00:00 in local time can be before 1970-01-01 00:00:00 GMT, mktime() can return negative value which is not supported on Windows. gmmktime() uses mktime() internally so it fails on negative timestamp returned by mktime(). I documented this. Previous Comments: ------------------------------------------------------------------------ [2004-08-06 21:30:25] vrana@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Unix epoch starts at 1:00 and Windows doesn't support negative timestamps. That's the problem. ------------------------------------------------------------------------ [2003-04-08 05:15:53] f dot vulto at re-base dot com Too easy to blame it on Windows as a bug. I think it's the timezone which is causing problems on Windows here as well. See also my comment on bug #14391: "gmmktime, gmdate work incorrect". Wouldn't things be fixed if PHP would just use the proper Windows API calls for timezone conversions instead of relying on UNIX setting of TZ environment variable? The TZ variable on Windows isn't reliable for Daylight Savings Time other than US rules or rules of local server timezone. I don't have PHP core coding experience so here are some useful links, anyone? :-) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore9 8/HTML/_crt__tzset.asp http://archive.devx.com/premier/mgznarch/vbpj/1999/08aug99/mt0899.pdf http://17slon.com/gp/gp/files/gptimezone.htm http://www.thedelphimagazine.com/samples/1175/1175.htm Freddy Vulto ------------------------------------------------------------------------ [2003-03-19 04:19:32] jsteeen at timecom dot com yes. please. add a comment to the online doc about the win bugs to both mktime and gmmktime. ------------------------------------------------------------------------ [2003-03-17 09:42:36] sniper@php.net This is not bug in PHP, but in Windows. We should mention this on the manual. ------------------------------------------------------------------------ [2003-03-17 08:52:33] jsteen at timecom dot com michael: "on systems where time_t is a 32bit signed integer, as most common today, the valid range for year is somewhere between 1902 and 2037" to my understanding, that includes 1970, in the valid range, or not? [1902<1970<2037] andrew: it seems your post is incomplete, so if you could complete, it, it might be of some help. then: i basically agree, but: this is a bug-db. the first thing we can do for the developers AND the community, is to report and document bugs properly. if a bug then gets marked as 'bogus', it will be ignored, i ensure you! so: maybe it's not as much as to 'get rid' of open bug-reports, but more about marking them properly if you see one. if there are 'unsolvable' bugs, i suggest they be marked as such [or as 'cannot be fixed at this point'] and not as 'bogus'. that would also make it easier for us to spot where the developers need help and kick in appropriately. your redirection to mktime only proves that any function dealing with unix timestamps is completely unreliable on win platforms and should -hence- not(!) be used. i consider this fact being worth documented somewhere. [eg: a db based on timestamps cannot be moved to another OS, since the stamps would 'shift'] ------------------------------------------------------------------------ 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 http://bugs.php.net/22635 -- Edit this bug report at http://bugs.php.net/?id=22635&edit=1