Not a bug... PHP uses the native system calls for this. The windows API simply returns different (wrong) results. There is nothing that can be done about it.

Derick

This still happens in PHP 4.2.0 under WinNT (dates before 1970 are invalid).  This makes it hard to use PHP with the MSSQL extension since it converts fields to strings, and therefore you *need* to be able to convert the strings it generates (such as "Sep 1 1969 12:00AM") to timestamps if you want to perform any manipulations (or present the date in a better format).

Obviously, Windows *can* cope with dates before 1970, as can every Windows application I know of, so it's very hard to understand *why* PHP is unique in not being able to cope.  Is there not even a workaround?

I agree with jasonh@trurocollege.ac.uk.  There has to be
a fix or workaround.  If windows is returning a different
format or whatever, there should be a configuration param
or a different routine provided.  Just like javascript and
other script engines have to deal with Microsofts demand
that everyone conform to them.

Classifying this bug as "bogus" is simply not satisfactory. The function is obviously using the wrong int size and messing up on unix times less than 1970-01-01 (Unix time zero).

This is DEFINATELY a serious and fatal bug. How can you validate a birthdate if customers are not allowed to be older that 32?

There are plenty of other time formats you can use for this.  See the calendar functions at php.net/calendar. 

Definitely a bug.  Folks normally use strtotime() to rearrange dates input by a user into a usable date.  Ubiquitous Dreamweaver codes:
  date("Y-m-d",strtotime($theValue))
to format all user-input dates. There isn't a calendar function you can use as a work-around (as rasmus suggested).

Martin