> > > No offense, but in TFM (which you have of course R), follow the 'Date
> > > Input Formats' link to:
> > >
> > >
> > >
> > > 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 
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'...


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to