Thanks heaps -- very reassuring :) Justin
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 -------------------- http://Indent.com.au Web Development & Graphic Design -------------------- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
