On Thu, Jan 14, 2010 at 2:53 PM, Adam Richardson <simpleshot@xxxxxxxxx>wrote: > I've not read this, but if the first valid date is Jan. 1st, 1970, then > passing that date back in the case of errors would lead to ambiguity. Is > it > a valid date or is it an error. Passing back the date of the day just > before (in terms of time, I think it's the second before) the first valid > date lets you easily identify an error. > > Again, I didn't read this anywhere, though, and I could be wrong. > > Adam > > On Thu, Jan 14, 2010 at 3:47 PM, Kim Madsen <php.net@xxxxxxx> wrote: > > > Hi guys > > > > I have a question: > > > > <snip> > > Ashley Sheridan wrote on 14/01/2010 19:20: > > > > MySQL uses a default "0000-00-00" value for date fields generally, but > > when converted into a timestamp, the string equates to a false value. In > > PHP, timestamps are numerical values indicating the seconds since > > Midnight of the 1st January 1969. As PHP uses loose data typing, false > > </snip> > > > > Adam Richardson wrote on 14/01/2010 19:25: > > <snip> > > 2. date returns 1969, because it's not passed a valid timestamp and it > > works from December 31, 1969 for any invalid date. > > </snip> > > > > Why is this? Unixtime starts at January 1st 1970 GMT (see for instance > > http://php.net/microtime), I've never heard of the other dates you > > mentioned. > > > > My guess is the time, date or GMT is wrong for Johns setup and that's why > > he get 1969 and not 1970, cause something is seting time in the past > Time zones. If I have PHP spit out a date for "0" as a string on my system, it comes back as 18:00 on December 31st, 1969, because I am in the Central time zone. // Todd
