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

=which is about where we came in, IIRC

> > =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
> timezone -- that is, the very same instant -- both asked for the current
> UNIX timestamp, we would both get the same answer.

=uh-oh. I may misunderstand UNIX timestamps then - perhaps I am assuming too
much similarity to date()?

=Date() is local-TZ aware, so I appear to have assumed that a timestamp is
also. What you are saying is that a timestamp is always GMT (regardless of
machine/opsys TZ) and only when passed to date() or somesuch is the 'time'
value manipulated (as well as its format) to become local. Correct?
I thought timestamps were set at the time on the local clock, and thus would
be different across TZs - date() is...

=as a Windows user I struggle to cope with some of these UNIX concepts, so I
hit Google - with no joy, and ripped through the SuSE manuals (I'm a closet
Linux user - will become one, just as soon as I can find the necessary spare
machine (and time!) - till then, the box of manuals, CD-ROMs etc lives in
the closet!) Would you believe, none appear to clarify this (maybe I'm using
the wrong terminology/barking up the wrong trees...).

=Like you (Mike), I'm living in Zulu-TZ (although unlike you, I'm not always
'here'), where it's not so easy to test for myself (and I'm not prepared to
jump onto client machines to 'play', at this moment).
- I double-checked with Asia this morning and things work exactly as they
should (at the application level) so I'm (relieved) confident that all is
well with the code.

=So as far as any processing goes, whatever I understood was the 'model' was
good enough to get the job done, however my 'model' of the way UNIX/PHP
works is slightly shaken, so I'm not a happy bunny...

=With relief that I didn't mislead Justin: the fact remains/we are
completely agreed - if you want to have a consistent database (for example)
with temporal data arriving from/going to different TZs, then the gm*()
functions are the ones that will offer the required international
consistency to convert timestamps to readable dates and v-v...

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

=and do so, very nicely, thank 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
> 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
> result; gmdate simply formats the timestamp, thus expressing it in GMT.
> I, too have wrestled with this quite a lot before eventually coming to
> 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!!!

Thanks for this,

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to