> -----Original Message-----
> From: DL Neil [mailto:[EMAIL PROTECTED]]
> Sent: 09 December 2002 10:50
[snip...]
> =now let's take a look at the UNIX Epoch. Various
> 'quotations' have surfaced
> in this email, and I don't recall that it is well discussed
> within the PHP
> manual (it being a UNIX definition after all...). The epoch 'began'
> 1Jan1970, sure enough (exactly as quoted). HOWEVER it is defined as
> beginning at Greenwich: 1Jan1970 at midnight UTC in Greenwich...
>
> =So a timestamp of 'zero' in London (UTC) would see the east coast of
> Australia at 39600 local (TZ of +1100 (hours)).
Er -- no, I think you've got that backwards. Unix timestamps are, as you
rightly say, seconds since 00:00 1-Jan-1970 GMT, so, at any instant, the
Unix timestamp is the same at every point on the globe. It's only the
*local* *times* (on the server, of course) that change. So, the Unix
timestamp of 0 represents:
00:00 1-Jan-1970 GMT
19:00 31-Dec-1969 on the east coast of Canada/USA
(5 hours behind GMT)
09:30 1-Jan-1970 in Australia's Northern Territory
(9.5 hour ahead of GMT -- I know this
one 'cos my sister lives there!)
>From this, you can see why the same time stamp might give you different
dates if your servers are in different timezones -- espacially ones as
widely different as Australia and Canada!
> =if at that very time I was in London and you in TZ+1100 and
> we waited one
> hour, the asked for the current timestamp: I would get 3600
> and you 43200.
Again, no: if I, at 01:00 local in GMT, and he at 12:00 local in a GMT+1100
timezone -- that is, the very same instant -- both asked for the current
UNIX timestamp, we would both get the same answer.
> =The reality is that everyone works off UTC (NB "GMT" whilst widely
> used/terminology within PHP is not the "internationally PC term") -
> including the (alert) Americans - the US military
> refers/referred to UTC/GMT
> as "Zulu time" (which has more to do with the alphabet than
> warriors). So if
> I'm in Germany and I'm phoning you early/late in the day, to
> avoid holding
> our conversation in a less socially-acceptable climate I
> would first compare
> my time against UTC (+0100) and then compare your time
> against UTC (+1100),
> do the math to get a difference of +10 hours, add that to my
> local time, and
> thereafter place/delay the call... (try doing this
> calculation based upon
> something like Indian Standard Time, and add a Daylight
> Saving/Summer-Time
> adjustment into the mix, just for 'fun'!?)
Well, the time/date functions provided in PHP can do all this for you.
> =In conclusion, (based upon my, cough, cough, many years of
> wrestling with
> this sort of thing) make all stored times UTC (gm*())
Yes -- as the Unix timestamp is an *absolute*, always expressed in GMT
regardless of where you are (or, rather, where your server is!), this is the
one to use as your base.
> - the
> RDBMS should not
> 'filter' timestamps - MySQL does not (for example), and then
> if you want
> 'local' times you can 'do the math' for either the server's
> TZ or (if you're
> really masochistic (?is that the word?)) the browser-client's
> local time.
> The 'silver lining' is that you can now easily accommodate temporal
> input/presentations to/from anyone, anywhere in the world -
> it is also easy
> to produce code to calculate the server's local time (for
> example), so that
> the same routine works regardless of where the server is
> located - where
> next year's new 'mirror' is to be located, anywhere in the world!
To amplify on this:
Doing a strtotime() or a mktime() will assume you are expressing the
date/time in the local (to the server) timezone, and do necessary
adjustments to produce your GMT-based Unix timestamp (unless, that is, you
pass a string to strtotime() which contains a timezone expression such as
EST or -0500!); gmmktime will assume you are providing a GMT date/time and
make no such adjustment.
Similarly, in the reverse direction, date() will take the GMT-based
timestamp, adjust it for local timezone and DST, if any, and then format the
result; gmdate simply formats the timestamp, thus expressing it in GMT.
I, too have wrestled with this quite a lot before eventually coming to this
understanding -- not helped by my location, which means that for half the
year I'm in GMT and so can't see the local effect of any corrections I'm
applying!!!
Cheers!
Mike
---------------------------------------------------------------------
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
