Thanks heaps -- very reassuring :)


on 09/12/02 9:49 PM, DL Neil ([EMAIL PROTECTED]) wrote:

> Justin,
> Jumping in late...
>>>> Daylight Savings Time?
>>> John, I think "Daylight Saving Time" creates a difference of 1 hour and
> not
>>> 1 day :)
>> True... but I checked it anyway -- by adding just one and two hours to the
>> stamp... which made no difference... but when I added 86400 to the stamp,
> it
>> all worked.
> =depends upon the time of day!
> (its a logic 'twister', like saying even a stopped clock is correct twice
> per day)
>>> Justin, it depends how you got your "timestamp" in the first place, I
>>> think...
>>> I could be wrong again here but aren't these different?
>>> mktime()
>>> gmmktime()
> =absolutely! One just 'works', the other relates everything back to GMT
> before performing the same calcs.
>> Actually, they were created with strtotime().  Note, I don't believe
> there's
>> anything wrong with the stamp itself.  The point is, the stamp is
> displaying
>> as two different dates using date() on two different servers, and I
> believe
>> this is not what date() is supposed to do.
>> Shouldn't the stamp for 12-09-2002 22:13:09 be the same on every server?
> =yes, no, not necessarily!
>> My rationale for this is that no matter where you are in the world, it is
>> always a certain number of seconds since 01-01-1970 00:00:00.
> =yes, no..., watch out for the interpretations that are applied EVERY time
> you call a function!
>> Perhaps strtotime() is NOT running off GMT, and perhaps date() is... there
>> has to be SOME confusion there -- either on my side, or in my choice of
>> functions, or SOMETHING :)
> =any call to system time will get you the time that has been set on the
> SERVER (although there is a PHP function for local-time, somewhere - have
> never used it). So the first question is, where is the server? The second
> question is, what time zone (TZ) has it been set to run within? (NB you can
> run a server in Sydney, but set its clock so that it 'appears' to be in
> Perth - if you really want to...)
> =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)).
> =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.
> So whereas I can subtract zero from current time and get one hour, you must
> subtract 39600 from 43200 to get the correct answer - in other words, don't
> use "zero", but 'Epoch-zero' adjusted for TZ.
> =as soon as you start to twist your mind around all this, you realise why Dr
> Who was a bit loopy about the size of telephone boxes, etc! Time travel is
> not for the faint-hearted (nor the mathematically-challenged/regular lottery
> ticket purchasers)!
> =PHP provides a solution in the gm*() series. The best/only solution is to
> find a common timebase. I've worked with American (and one Japanese)
> companies who (initially) insisted on time-basing everything to HEAD OFFICE
> (caps to demonstrate scale of self-importance, eg "this report must be in by
> 1700 in ..."), and usually they end up tripping themselves up, and thus
> provide me with the 'proof' of the illustrations/arguments I made at the
> design stage (that they chose not to listen to...)
> =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'!?)
> =In conclusion, (based upon my, cough, cough, many years of wrestling with
> this sort of thing) make all stored times UTC (gm*()) - 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!
> =Yes, you may have a chunk of work in front of you right now, but it will
> save time (and your sanity) in the long-run and as you expand more
> internationally...
> =Yell if you need more,
> =dn

Justin French
Web Development & 
Graphic Design

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to