> > =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 GMT+1100 > 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 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!!! Thanks for this, =dn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
