> -----Original Message-----
> From: DL Neil [mailto:[EMAIL PROTECTED]]
> Sent: 09 December 2002 10:50

> =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



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
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

Reply via email to