ID: 22635 Updated by: [EMAIL PROTECTED] Reported By: jsteen at timecom dot com -Status: Analyzed +Status: Closed Bug Type: Documentation problem Operating System: win32 PHP Version: 4.3.1 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [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] [EMAIL PROTECTED] 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'] ------------------------------------------------------------------------ [2003-03-12 15:37:51] [EMAIL PROTECTED] jsteen at timecom dot com: If you're pissed that the time functions are so 'buggy' on Win32, then why don't you step into the ring and help us debug it? Become part of the community, but don't drive the community away because you didn't get an answer you wanted. Please reopen this bug as you feel necessary, but i'm marking it as a bogus report due to the fact that it's an imcompatibility between Win32 and *nix systems, and also the fact that we can I'd finally like to redirect you to http://www.php.net/manual/en/function.mktime.php so you can read the user comments. Apparently different windows systems handle the timestamp differently. As said earlier, it's an incompatibility. ~ Andrew Heebner ~ Andrew Heebner ------------------------------------------------------------------------ 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
