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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
