> > > 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
> > 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
> > 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
> > 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
=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
=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
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'...
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php