Monday, December 04, 2006
Local Times are Ambiguous!
This issue rarely gets a lot of attention, so I thought this should be brought to everyone's attention right away. Local times can be ambiguous and should be used for display purposes only. When storing your data, use Universal Time (also known as Coordinated Universal Time, UTC, Greenwich Mean Time, or GMT), which is not ambiguous.
What do I mean when I say that local times are ambiguous? Consider the times during a switch to and from daylight savings time. For this example, assume that the switches occur at 2:00am, and daylight savings time "springs forward" (adds an hour in the Spring) and "falls back" (removes the hour in the Autumn). During the spring forward, the clock advances like this:
01:58am - - 01:59am - - 03:00am -- 03:01am
Note that 02:00am through 02:59am do not exist! What time is it when it is 02:30am local time? It's fairly safe to assume that 02:30am means 03:30am, but things get a lot more complicated during the fall back:
01:58am - - 01:59am - - 01:00am -- 01:01am
Note that the time between 01:00am and 01:59am is actually repeated! What time is it when it is 01:30am? In reality, this time can refer two two different times! If you had something scheduled to happen at 01:30am, it could happen twice that day!
Another problem with local times is that they change if your location changes. For example, let's say that you recorded appointments using local times in a database that was located in the Eastern Time Zone, then your company moved all its operations to the west coast. Now, your clients' and server's local time zone is the Pacific Time Zone, and all your appointments are 4 hours off!
Universal Time does not have any daylight savings time, or any other quirky rules like local times. It is always the same in any location, and is never ambiguous. So, store your data using Universal Time, and only convert to local time immediately before displaying the time to the user.
What do I mean when I say that local times are ambiguous? Consider the times during a switch to and from daylight savings time. For this example, assume that the switches occur at 2:00am, and daylight savings time "springs forward" (adds an hour in the Spring) and "falls back" (removes the hour in the Autumn). During the spring forward, the clock advances like this:
01:58am - - 01:59am - - 03:00am -- 03:01am
Note that 02:00am through 02:59am do not exist! What time is it when it is 02:30am local time? It's fairly safe to assume that 02:30am means 03:30am, but things get a lot more complicated during the fall back:
01:58am - - 01:59am - - 01:00am -- 01:01am
Note that the time between 01:00am and 01:59am is actually repeated! What time is it when it is 01:30am? In reality, this time can refer two two different times! If you had something scheduled to happen at 01:30am, it could happen twice that day!
Another problem with local times is that they change if your location changes. For example, let's say that you recorded appointments using local times in a database that was located in the Eastern Time Zone, then your company moved all its operations to the west coast. Now, your clients' and server's local time zone is the Pacific Time Zone, and all your appointments are 4 hours off!
Universal Time does not have any daylight savings time, or any other quirky rules like local times. It is always the same in any location, and is never ambiguous. So, store your data using Universal Time, and only convert to local time immediately before displaying the time to the user.
