UTC time
Wednesday, March 7th, 2007I saw this posted on the Patch Management mailing list and thought it was well put so I decided to post it here.
This is in a thread about what order to apply all of the Daylight Savings Time (DST) patches which is why you see references to Exchange and calendaring.
Here’s the original post on the mailing list:
http://marc.theaimsgroup.com/?l=patchmanagement&m=117328106928017&w=2
UTC is not GMT. UTC is the number of seconds since the arbitrary Unix “epoch” of 00:00 970-01-01 GMT. No matter what time zone you live in, UTC will always uniquely and exactly define a precise moment in time.
This is how computers in Japan and Los Angeles can agree on what time it is. LA doesn’t say say “13:33:00 2007-03-06 PST” and Japan doesn’t respond “22:33:00 2007-03-06 JPN”. LA says ‘1173216780′ and Japan says ‘1173216780′. Five minutes later they both agree that it is ‘1173217080′. There are *no* time zones in UTC because it doesn’t make sense to. You don’t time shift the number of seconds relative to an event. The number of seconds since epoch doesn’t vary depending on where you are on the planet. It’s an absolute. If you’re writing an app that cares about timestamping when an event occurs, you *always* use UTC.
I enter an appointment in Tokyo for 9 am New York time on March 12th 2007 on my calendar. BetterExchange stores this time as ‘1173686400′. Now, no matter where I am, my calendar entry will show that at 9 am New York time aka 2 pm GMT aka 12 midnight Tuesday morning Tokyo I have a meeting. It’s precise because it allows Exchange to store the context.
All MS has to do:
1. Store UTC in Exchange
2. Give Outlook the ability to specify a Time Zone during meeting creation times.
Now you can do magical things like schedule a meeting between yourself and someone in a different time zone, and neither system needs to know about that time zone shift in any way. They all speak UTC so they know exactly when you’re talking about. As long as the systems know their own local time zone they can always display the time accurately to the user.
The 32-bit vs 64-bit problem, the Year 2038 problem, is another Y2k rollover issue. On January 19th, 2038, the value for UTC will exceed the maximum positive value of 32-bit signed integers and wrap negative. Any system still using a 32-bit signed integer for UTC will believe it to be 1901 rather than 2038. Using a signed 64-bit integer extends UTC to almost 300 billion years.
However, the point of that paragraph was to note the only benefit of using non-timestamped date strings instead of UTC integers or decimals: You won’t wrap around until the year 10,000. Of course, anybody who plans to be using Exchange 2003 or Exchange 2007 in 2038 has serious
problems. So the design “feature” of date robustness in exchange for time zone nightmares is completely worthless. Nobody will be using an email server in 2038 from this decade. 32-bit limits are a moot point, so any advantage Exchange might have over 32-bit UTC groupware is irrelevant.
–
Brandon Aiken
CS/IT Systems Engineer