Page 5 of 5

Re: Timezone Strategies

Posted: Tue Mar 17, 2009 3:18 pm
by André D
alixaxel wrote:this forum (phpBB) for instance has an bug where it says that "All times are UTC [ DST ]", instead it should read "All times are GMT [ DST ]" because UTC is DST agnostic. GMT on the other hand has it's correspondent DST timezone (GST or BST I believe) which is UTC-1.
I'm not sure that I agree with this. I'm not saying that you're wrong; you seem knowledgable, but I may not understand what you're trying to say. GMT does not change for daylight savings. In the UK, where GMT is the official time, they only use it during winter. During summer, they use British Summer Time (BST), which is GMT+1.

Everyone else in the world uses UTC as the official time reference, not GMT. So for our purposes, we can consider GMT to be a timezone that is UTC+0.
kaisellgren wrote:My friend from NYC is GMT-5 and I am GMT+2 so I am 7 hours ahead of his time, but now, however, he went to summer time so is he UTC-4 while I am UTC+2? Or in other words, is he GMT-5+DST and I am GMT+2 (no DST)?
You're mixing GMT with UTC which causes confusion. In the context of this thread, when we talk about GMT we are using it as a time reference. GMT should no longer be used in this way because it was replaced by UTC. In other words, forget about GMT and use UTC instead.

Your friend's time is GMT-5 and yours is GMT+2. When he switches to daylight savings he is GMT-4. Using UTC is no different. He is on UTC-5 and you are on UTC+2. When he switches to daylight savings he is on UTC-4. I look at GMT and UTC as two different units of measurement, which happen to be equal to one another.
alixaxel wrote:the best way to deal with dates is to always grab the date and on the local user timezone and convert/store it in UTC, then you can convert it again to the timezone your user prefers.
This I agree with, and I proposed a simple way of doing this with MySQL's TIMESTAMP columns in my first post in this thread.

Re: Timezone Strategies

Posted: Tue Mar 17, 2009 3:32 pm
by kaisellgren
alixaxel wrote:No, like Andre D very well said, UTC expresses timezones and it's respective summer/winter times as offsets from the same "timezone" of standard/winter GMT, this forum (phpBB) for instance has an bug where it says that "All times are UTC [ DST ]", instead it should read "All times are GMT [ DST ]" because UTC is DST agnostic. GMT on the other hand has it's correspondent DST timezone (GST or BST I believe) which is UTC-1..
I have always been in UTC+2 myself. Is this country specific?

What I have always been doing so far in my life is this:
Timezone 1 (mine): +2
Timezone 2 (target): +6

Calculate difference: abs((T1+DST)-(T2+DST))

Re: Timezone Strategies

Posted: Tue Mar 17, 2009 3:43 pm
by kaisellgren
Reading Wikipedia is painful. I decided to Google instead and found much better responses. ;)

http://www.timeanddate.com/worldclock/city.html?n=179
Standard time zone: UTC/GMT -5 hours
Daylight saving time: +1 hour
Current time zone offset: UTC/GMT -4 hours
Time zone abbreviation: EDT - Eastern Daylight Time
That explains everything. :drunk:

Re: Timezone Strategies

Posted: Tue Mar 17, 2009 7:12 pm
by alixaxel
Kai in your example the original timestamp is in UTC but in real world scenarios that's not always the case, suppose for example that you want to receive the local time in NYC and display it back to the Finland user, in his local time - how you you do that?

This is how I go around it:

Code: Select all

 
<?php
 
echo Timestamp_Helper('jS F Y H:i:s', '@1236439969', 'America/New_York', 'Europe/Helsinki');
 
?>
 

Re: Timezone Strategies

Posted: Tue Mar 17, 2009 7:42 pm
by kaisellgren
alixaxel wrote:Kai in your example the original timestamp is in UTC but in real world scenarios that's not always the case, suppose for example that you want to receive the local time in NYC and display it back to the Finland user, in his local time - how you you do that?
Huh? When the NYC guy views it - it's in his local time, when the Finland guy views it - it's in his local time. So, each person around the world has a clock value to relate to. So, I can look at my clock and notice that the wtvr it is was created one hour ago... then the NYC guy can notice the same thing (one hour ago) since it was correctly translated into his local time.

If you mean how to display NYC's local time to F guy, then just compare the difference (without forgetting the possible DST).

Re: Timezone Strategies

Posted: Tue Mar 17, 2009 7:56 pm
by alixaxel
kaisellgren wrote:
alixaxel wrote:Kai in your example the original timestamp is in UTC but in real world scenarios that's not always the case, suppose for example that you want to receive the local time in NYC and display it back to the Finland user, in his local time - how you you do that?
Huh? When the NYC guy views it - it's in his local time, when the Finland guy views it - it's in his local time. So, each person around the world has a clock value to relate to. So, I can look at my clock and notice that the wtvr it is was created one hour ago... then the NYC guy can notice the same thing (one hour ago) since it was correctly translated into his local time.

If you mean how to display NYC's local time to F guy, then just compare the difference (without forgetting the possible DST).
I was just making a point on how complex a simple and often verified situation can become, using the date_default_timezone_set() strategy you described above works but just for simpler cases (normally UTC or server time to a defined timezone), that's why the new DateTime(Zone) classes are so useful, if you don't believe me just try to convert 14 PM @ 2009-03-18 NYC time to FI time, if you come up with a simple solution without using DateTime(Zone) let me know.
André D wrote:
alixaxel wrote:this forum (phpBB) for instance has an bug where it says that "All times are UTC [ DST ]", instead it should read "All times are GMT [ DST ]" because UTC is DST agnostic. GMT on the other hand has it's correspondent DST timezone (GST or BST I believe) which is UTC-1.
I'm not sure that I agree with this. I'm not saying that you're wrong; you seem knowledgable, but I may not understand what you're trying to say. GMT does not change for daylight savings. In the UK, where GMT is the official time, they only use it during winter. During summer, they use British Summer Time (BST), which is GMT+1.

Everyone else in the world uses UTC as the official time reference, not GMT. So for our purposes, we can consider GMT to be a timezone that is UTC+0.
Yes, you're right indeed, UTC is basically the same as GMT, I think I got this info wrong because I associated GMT with the actual place "Greenwich", which is in London and has DST (BST) - my bad.

Re: Timezone Strategies

Posted: Tue Mar 17, 2009 8:50 pm
by kaisellgren
alixaxel wrote: just try to convert 14 PM @ 2009-03-18 NYC time to FI time

Code: Select all

header('content-type: text/plain');
 
// Create NY time 14 PM @ 2009-03-18
date_default_timezone_set('America/New_York');
$nytime = mktime(14,0,0,3,18,2009);
 
// Make it into FI
date_default_timezone_set('Europe/Helsinki');
echo date('H @ Y-m-j',$nytime)."\n14 PM @ 2009-03-18\n"; // echo the NY time to compare
Results:
20 PM @ 2009-03-18
14 PM @ 2009-03-18
As you can see, the difference is 6 hours, which is correct since FI doesn't have DST yet and NY has.

Re: Timezone Strategies

Posted: Wed Mar 18, 2009 7:24 am
by alixaxel
Great! I could have swear that I've tried a similar example one or two years ago and it produced inconsistent results.

Anyway, thanks for the snippet!

Re: Timezone Strategies

Posted: Thu Mar 19, 2009 6:41 am
by batfastad
Just thought I would add my 2p's worth to this ;)
On our intranet application I had some problems dealing with timezones. For the invoicing section, the user enters a date in dd/mm/yy format, and this was getting converted to a unix timestamp by the mktime() function and stored in my DB in unix timestamp format.
It was working great, until I realised that mktime() was taking the user's timezone into consideration, giving incorrect invoice dates when viewing from different timezones and when daylight savings switched on/off.
So where you want to store/output an "absolute" date/time, I found the gmmktime() and gmdate() functions worked perfectly instead.

Hope this helps, it took me a couple of weeks to get that all straightened out :)