RE: [PHP] date() on two diff. servers
-Original Message- From: DL Neil [mailto:[EMAIL PROTECTED]] Sent: 10 December 2002 19:52 =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...). Well, I think the PHP manual is pretty good about this -- all the pages I've looked at are careful to add the GMT timezone indicator when referring to the base date of the Unix epoch, which is pretty much what tipped me off to the correct interpretation. (If you find a reference there that doesn't include the GMT indicator, I reckon that would be worth a bug report in the Documentation problem category.) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] date() on two diff. servers
Mike, No complaints about explanations in PHP manual - I often say that it IS a cut-above the average. However it does NOT explain the underlying concepts of timestamps, (quite rightly) expecting that we pick up such from other/more appropriate sources. Hence my comments are refering to such sources/attempting to find such sources... Like you, when I re-read that entry in the PHP manual (after your informative reply) I 'saw' the logic and discovered that I had to move the 'location' in my mind-map where I had framed the GMT/TZ adjustment. Fortunately it didn't nullify any design decisions I've made/relied upon. Unfortunately *NIX sources thus far consulted don't seem to feel it necessary to do the same/print anything confirming (and many of them most careless in your GMT point) - and hence the discomfort. It is always difficult to learn new things, and if not more so, can be v.awkward trying to adapt from one philosophy to another, eg Windows to *NIX. Getting the terminology straight is one thing, getting the model worked out another. I don't doubt what you say/am happy to be shown to be wrong, but would sure like to 'prove' it. As I say, am probably just barking up the wrong (Christmas) tree(s). No worries - it's familiar territory! Thanks for your help, =dn -Original Message- From: DL Neil [mailto:[EMAIL PROTECTED]] Sent: 10 December 2002 19:52 =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...). Well, I think the PHP manual is pretty good about this -- all the pages I've looked at are careful to add the GMT timezone indicator when referring to the base date of the Unix epoch, which is pretty much what tipped me off to the correct interpretation. (If you find a reference there that doesn't include the GMT indicator, I reckon that would be worth a bug report in the Documentation problem category.) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] date() on two diff. servers
=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
Re: [PHP] date() on two diff. servers
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
Re: [PHP] date() on two diff. servers
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),
RE: [PHP] date() on two diff. servers
-Original Message- From: DL Neil [mailto:[EMAIL PROTECTED]] Sent: 09 December 2002 10:50 [snip...] =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! =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. =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. =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!!! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] date() on two diff. servers
Hello gurus,
Ford, Mike [LSS] [EMAIL PROTECTED] wrote:
[snip]
To amplify on this:
...
[/snip]
Interesting comments! ...not sure if I understood everything though :(
Anyway, for Justin's original problem, I think it'll be solve by simply
doing two things:
1. Add GMT to the end of the string being passed to strtotime().
2. Use gmdate() instead of date().
Ex.
?php
$my_date = December 10, 2002 22:13:09;
$my_date .= GMT;
// testing on my test server...
// with the string GMT, echo $my_stamp - 1039558389
// without it, echo $my_stamp -- 1039525989
$my_stamp = strtotime($my_date);
echo $my_stampbr /;
echo gmdate('D, d M Y G:i:s', $my_stamp);
// Conclusion: Using strtotime() with GMT will create
// a timestamp that if used with gmdate() will produce
// desired result whichever timezone you run the script.
?
That should work. If not, tell me about it later--I'm more than happy to be
corrected. But for now, I'll be taking some rest :)
- E
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] date() on two diff. servers
Daylight Savings Time?
---John W. Holmes...
PHP Architect - A monthly magazine for PHP Professionals. Get your copy
today. http://www.phparch.com/
-Original Message-
From: Justin French [mailto:[EMAIL PROTECTED]]
Sent: Sunday, December 08, 2002 8:59 PM
To: php
Subject: [PHP] date() on two diff. servers
Hi,
I'm running the following code on two servers:
?
$stamp = 1039525200;
echo date('D, d M Y',$stamp);
?
On my local development box (Free BSD, PHP 4.1.1, on AUSTRALIAN time),
the
above echo's Wed, 11 Dec 2002 (I consider this to be the correct
date.
However on the live server (Red Hat, PHP 4.2.3, hosted in CANADA) the
above
code echo's Tue, 10 Dec 2002.
Now, what could be causing this problem? IMHO, no matter where you
are in
the world (or more to the point, what timezone you are in), 1039525200
seconds after a certain date (in this case the unix epoch) should be
another
certain date, yes?
What could be causing this difference? What should I talk to my host
about,
or look for?
Thanks,
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] date() on two diff. servers
Hello, John W. Holmes [EMAIL PROTECTED] wrote: Daylight Savings Time? John, I think Daylight Saving Time creates a difference of 1 hour and not 1 day :) Anyway, I live in a place where we don't practice this so I could be wrong... ...[snip]... Now, what could be causing this problem? IMHO, no matter where you are in the world (or more to the point, what timezone you are in), 1039525200 seconds after a certain date (in this case the unix epoch) should be another certain date, yes? 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() - E ...[snip]... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] date() on two diff. servers
But, then again, it could be just because the other server's time is really late... (caused by old motherboard batteries, etc.) - E @ Edwin [EMAIL PROTECTED] wrote: Hello, John W. Holmes [EMAIL PROTECTED] wrote: Daylight Savings Time? John, I think Daylight Saving Time creates a difference of 1 hour and not 1 day :) Anyway, I live in a place where we don't practice this so I could be wrong... ...[snip]... Now, what could be causing this problem? IMHO, no matter where you are in the world (or more to the point, what timezone you are in), 1039525200 seconds after a certain date (in this case the unix epoch) should be another certain date, yes? 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() - E ...[snip]... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] date() on two diff. servers
on 09/12/02 1:30 PM, @ Edwin ([EMAIL PROTECTED]) wrote: 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. 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() 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? 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. 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 :) 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
Re: [PHP] date() on two diff. servers
Hi,
Monday, December 9, 2002, 11:59:07 AM, you wrote:
JF Hi,
JF I'm running the following code on two servers:
JF ?
JF $stamp = 1039525200;
JF echo date('D, d M Y',$stamp);
?
JF On my local development box (Free BSD, PHP 4.1.1, on AUSTRALIAN time), the
JF above echo's Wed, 11 Dec 2002 (I consider this to be the correct date.
JF However on the live server (Red Hat, PHP 4.2.3, hosted in CANADA) the above
JF code echo's Tue, 10 Dec 2002.
JF Now, what could be causing this problem? IMHO, no matter where you are in
JF the world (or more to the point, what timezone you are in), 1039525200
JF seconds after a certain date (in this case the unix epoch) should be another
JF certain date, yes?
JF What could be causing this difference? What should I talk to my host about,
JF or look for?
JF Thanks,
JF Justin French
JF
JF http://Indent.com.au
JF Web Development
JF Graphic Design
JF
Put this at the top of your page
$tz = getenv('TZ');
if($tz != 'Australia/Brisbane') putenv(TZ=Australia/Brisbane);
--
regards,
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] date() on two diff. servers
Justin French [EMAIL PROTECTED] wrote: [snip] Perhaps strtotime() is NOT running off GMT, [/snip] Bingo! ...or, Bull's eye!, whatever :) Anyway, I think this is implied in the manual. http://www.php.net/manual/en/function.strtotime.php Also, check User Contributed Notes: piran at pobox dot com php at webdevelopers dot cz HTH, - E -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] date() on two diff. servers
on 09/12/02 3:06 PM, @ Edwin ([EMAIL PROTECTED]) wrote: [snip] Perhaps strtotime() is NOT running off GMT, [/snip] Bingo! *GULP*... so, what we're saying is, that if I intend to pass data around on multiple servers (in different timezones) using a unix timestamp for dates (which i prefer to do), I should be using gmdate() and gmmktime() rather than date() and strtotime()? That will sure as hell be a few lines of code to dig through I'll also need an accurate (and daylight savings compliant!) way of determining the how far ahead of the GMT the server currently is, or for a specific timezone for a specific project (eg this current one, which is basing it's dates on Sydney, Australia. 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
Re: [PHP] date() on two diff. servers
Justin French [EMAIL PROTECTED] wrote: on 09/12/02 3:06 PM, @ Edwin ([EMAIL PROTECTED]) wrote: [snip] Perhaps strtotime() is NOT running off GMT, [/snip] Bingo! *GULP*... so, what we're saying is, that if I intend to pass data around on multiple servers (in different timezones) using a unix timestamp for dates (which i prefer to do), I should be using gmdate() and gmmktime() rather than date() and strtotime()? I'm afraid so... That will sure as hell be a few lines of code to dig through Well... just hope that others chime in and suggest a better solution :) I'll also need an accurate (and daylight savings compliant!) way of determining the how far ahead of the GMT the server currently is, or for a specific timezone for a specific project (eg this current one, which is basing it's dates on Sydney, Australia. If I understand the problem correctly and if my understanding of the functions are correct, I'm not sure if you'd really need something like this. Consider this: ?php $timestamp_local = time(); $timestamp_gmt = gmmktime(); $run_local = date(F j, Y, G:i:s, $timestamp_local); $run_gmt = gmdate(F j, Y, G:i:s, $timestamp_gmt); echo Local Timestamp: $timestamp_localbr /; echo GMT Timestamp: $timestamp_gmtbr /br /; echo This script was run on: br /; echo $run_local (DATE with Local Timestamp)br /; echo $run_gmt (GMDATE with GMT Timestamp)br /; ? As you can see, although the timestamps are different, they produce the same results. So, *I think*, using gmdate() and gmmktime() would be enough. (Or, if you insist on using strtotime(), consider the example(s) in the User Contributed Notes I mentioned earlier.) I hope this give you some hints. - E -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
