Works fine with Linux.

WE F...ING KNOW mktime, gmmktime etc. WORK FINE ON *NIX!
THIS IS A WIN REPORT!

[flame: on]
is it a new policy on bugs.php.net to NOT read post headers/declarations, write "works fine with linux" as answer, and put the bug on 'BOGUS'?

i'm among the many users that are pissed that all the timestamp-functions are buggy on win. ok. fine. deal. but then please take our reports seriously and put a proper comment in the man! i really begin to wonder whether you're not just too lazy to seriously deal with it if i get this sorts of answers.
[flame: off]

so why does 1.1.1970 not have 24h?

please omit any of the usual answers, like:
- works fine for linux
- blame MS

Please read the fine manual. From <http://www.php.net/manual/en/function.mktime.php>:

"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".

If you are using values outside this range, you get undefined behaviour.

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

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']

This is not bug in PHP, but in Windows.
We should mention this on the manual.

yes. please. add a comment to the online doc about the win bugs to both mktime and gmmktime.

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

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.

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.