Torben, > > > No offense, but in TFM (which you have of course R), follow the 'Date > > > Input Formats' link to: > > > > > > http://www.gnu.org/manual/tar-1.12/html_chapter/tar_7.html > > > > > > You will find this sentence: > > > > > > The construct 'month/day/year', popular in the United States, is > > > accepted. > > > > > > In other words, '10/12/2002' should work fine with strtotime(). The > > > problem is elsewhere. > > > > > > =One thing for sure, I'm not going to get into an argument with the guy who may >well have written that very part > > of the manual ! > > Well, I didn't write that bit--and being an author doesn't necessarily > make me any more likely to be correct--just more publicly wrong when I > screw up. :)
=ah the joys of leadership, and the "loneliness of command"! =I have a healthy respect for the PHP manual - and thus, its authors. It is unusually complete (for an open source product) and very readable. =I also make extensive use of the PHP-ER. > > =The -1 is the key indicator. > > Yeah, I forgot to mention to Toni why $date3 was so weird--feeding a > string instead of a timestamp to date(). > > > =Rather than majoring on the manual, I was working on Toni's email address (which >told me very little) and the > > fact that she is on the US Pacific Coast. In other words, her server time zone >(which affects the way data > > functions work) is likely subject to Summer Time discontinuities. This combined >with the date being converted > > back and forth with datetime formats, crosses the from one day to the other. > > Yeah, that's what I figured too (being in Vancouver, I run into this > problem every so often). =and I've just realised that I wrote "US Pacific Coast" which will attract comments from Canucks like a lightning rod - excuse: I'm 'talking' with a colleague in San Diego... (he's having his chocolate biscuit and coffee for afternoon break - and I'm having something similar for a bedtime snack - here, have one yourself) =We still don't know where Toni and/or her(?) server are actually located. I wait with bated breath... =As someone who works with(in) international organisations and moving around (the world) frequently, I pay a lot of attention to where I am, and what time it is - and have a glowering dislike of ignorami who phone me at 0400 (local) having decided that lunchtime their time must be a 'good time' or who miscalculated thinking that it was actually 1600! =This topic confuses the life out of 'normal' people - and the summer time changes producing discontinuities so that one hour ago, may not in fact have 'happened' one hour previously, is a real mind-bender. Guess such people should be prohibited from flying/sailing across the International Date Line! =A few years ago, I considered working on Y2K projects to have brought me full circle (of the clock?) having spent quite a bit of time early in my career writing time-date subroutines for newly acquired machines/operating systems. Now I find myself back in a similar arena with PHP/MySQL. =My recommended solution is always to refer everything to a 'constant' time. That is to say, not use local summer time, or in the case of multiple time zones use UTC/Zulu (in PHP the gm* functions - as in GMT). I have a standard 'lecture' on the subject, which has been thrown at various lists, from time-to-time. Last time I reviewed it, I was trying to remember where I had read a really good write-up about the 'confusion of time', so thanks for reminding me about the GNU docs reference (ex-PHP manual, strtotime() ), because that's where it is! =Now if you could find me a similarly logical cure for 'jet lag'... =Regards, =dn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
