Designing "Time Zone conversions"

Kathy Kam Designing Time Zone conversions | debt settlement program

Kathy Kam Designing Time Zone conversions | debt settlement program — Fri, 19 Jun 2009 16:35:06 GMT

PingBack from http://edebtsettlementprogram.info/story.php?id=22783

Kathy Kam Designing Time Zone conversions | patio set

Kathy Kam Designing Time Zone conversions | patio set — Thu, 18 Jun 2009 05:23:12 GMT

PingBack from http://patiosetsite.info/story.php?id=853

pacific standard timezone conversion

pacific standard timezone conversion — Tue, 10 Jun 2008 20:07:55 GMT

PingBack from http://krista.bigpicturesite.com/pacificstandardtimezoneconversion.html

re: Designing "Time Zone conversions"

Steve — Fri, 15 Sep 2006 23:10:47 GMT

I have been struggling with this issue for some time. I have a scheduling utility that takes a TZ specific DateTime, and I need to convert that to local system time to know when to run.

Also, it is possible to overload, inherit, partial, or by any means derive from the DateTime structure? Then I could add some of the features I need.

Is modifying System.DateTime reasonable for a Time Zone/Offset aware DateTime object?

Kathy Kam — Tue, 05 Sep 2006 10:58:17 GMT

So, in my previous "Designing Time Zone Conversion" post, a few readers asked whether we can update System.DateTime...

re: Designing "Time Zone conversions"

John Glassman — Tue, 08 Aug 2006 00:58:26 GMT

In Jonathan Allen reply above, he brings up the issue of an implicit adjustment for DST to a dateAdd calculation. While I would find optional argument to support this in an interface very useful, I would caution against having any such behavior a default. Comparisons to the time line against fixed units of time are fundamental to many business rules and SLA's (service level agreements) and critical to correct accounting and billing practices for countless purposes. Such a behavior may certainly make it simpler to produce checks to see if an end time properly falls withing a set turn around time as time stamps could be directly compared with the result of the DateAdd, DateDiff, or whatever interval a range is based on. However, the use of these functions are fundemtal to existing calculation that may also then use addition inputs to adjust for DLS or Time Zone differences, especily if UTC time is not availble in the source data. If I add 5 hours to a datetime value, I should always expect it to show me a result time that is exactly 5 hour ahead, regardless of the calendar date and DST settings. But adding an ApplyDST boolean, and a zone id as an option would really be keen for a lot of applications and would simplify the production of such code. Any chance for getting these sort of time zone transforms built into SQLserver and SSIS?

re: Designing "Time Zone conversions"

Michael Giagnocavo — Thu, 20 Jul 2006 02:20:59 GMT

Hi Kathy, thanks for writing back! I love discussions too.

"
>>Why is storing "Pacific Time" not sufficient?
>
>Storing just "PST" is insufficient, because "PST" is simply an ID for you to look up the actual time zone rules. Different

>machine can have different DB. So your actual time will be different if you only store the ID.
>
>E.g.
>Machine A has the following PST rule:
>Offset = -8 hours
> <snip>
>Then.. March 31st 6:00pm (PST) will represent different time for Machine A and Machine B. Conversions between UTC and other

>time zones will result in different values.
"

**
But that's what we have now. If someone doesn't install a time zone update, then if I tell them "hey, meet you at 5PM Pacific

Time", they'll show up at a different UTC time than I would expect. I don't think it's unreasonable to have to have people to

install updates to get correct time display. As you pointed out, the rules change year to year (sometimes as fast as a

month), so the database will be large, and we can't be attaching that every time.
**

"
>"Physical location has nothing to do with which timezone you choose,"
>
>Physical location has everything to do with which time zone you choose. Our time zones are being differentiated by location!
"
**
OK, I'll admit I chose some very poor wording. I meant to say that physical location alone cannot determine time zone.

Someone could be travelling, be working with other users and hence have their time zone set differently, etc. On all our

server software, we set the clocks to UTC, and store all dates in UTC (so we never get burned by DST).

I wouldn't be surprised if, at some point in the future, some political/religious group declares one time zone, and another

declares another, for the same latitude and longitude! Indeed, seeing how countries are prone to dispute territories, I'd be

pretty certain this will arise (if it has not already). My point is that even if we did have an XYZ associated with a date

time, it would not give us enough information.
**

"
>People doesn't care about the time zone they are selecting. They only care about the time of day it is in a particular

>location. When I call home to Hong Kong, I don't care what time zone they are in. All I care about is that I don't wake my

>parents up at 3am in the morning. Users want a easy way to deal with time zone.Time zone gives people headache. Even the

>best of us! :) The challenge is in how much we encapsulate and how much flexibility we allow our users to have. Do our

>developers need to know about the actual rule changes? How much flexibility do we give them? Since we're the BCL, and the

>"B" really stands for "broad variety of users". This is the design challenge I am trying to highlight in this post.
"

**
I know the responsibility of being on the BCL must be awesome, and I envy you guys :). I think the main difference in

viewpoints is what you've highlighted here. If you view it from the point of "a person just wants to have their appointments

work", then you can take a lot of freedom. But, each app has to deal with this stuff its own way. For a simple appointment in

Outlook (i.e., just a reminder to myself), it's obviously really easy. Store your information in the local time and the OS

takes care of you.

However, how does an app differentiate:
- Tied to another time zone
- Tied to a specific offset
- Tied to the local system time (I want to wake up 9AM. If I move around the world, I want it to be 9AM.)

You can replicate these things in Outlook. If you are scheduling with n people, some in DST-enabled time zones, some not, and

someone gets an update -- what did they actually agree on as the time? I ran into this a year ago. I lived in a non-DST zone

(UTC-6), and had agreed to meet at 11AM "MDT" (UTC-6). Come fall, what time were we supposed to meet at?

In the Utah example -- how does my time change from "Mountain Time" to "Utah Time"? If I manually select it, am I saying

"hey, I moved from Colorado to Utah"? If it auto updates, how does it know that chaning the time is correct?

I love it when Microsoft solves a hard problem for us (that's why MS is so big, I think?). That makes devs love MS. But, we

should have to enroll in this functionality explicitly (even if it's only a few lines of code, or heaven forbid, a wizard

;)), rather than letting it happen "automagically". A good example is the whole SOAP DateTime problem, where, IIRC, the

serialization always embedded a UTC offset, creating a lot of problems (I was hit by it a long time ago), since the time zone

might have been agreed on explicitly by the other side.

I'd suggest that the APIs easily allow us to detect when a time zone was shifted, and then manipulate them. The application

then needs to determine if/how it wants to update data, and what that entails in its context. For instance, if my

appointments just shifted because Political Leader decided that if we offset by two hours for DST, maybe I (the user) will

say, no, this appointment is a picnic, so I need it to stay relative to the sun. Or, perhaps, the application needs to send

out sync messages or who knows what.

A thing I love about the .NET and the BCL is that we can do things many ways. And a lot of value of the BCL is making

classes/methods that wrap up otherwise available functionality. File.ReadAllLines is a great example of this. So, in the

concept of dealign with changing time zones, perhaps we should be able to store a DateTime with a few extra bits of data so

that the application can indicate if there is a time zone, and if so, what meaning does that have in light of changing zones

(i.e., Mountain -> Utah), updates (new DST rules), and so on. Then, things can "magically" be converted for the app, and the

dev has just delivered a lot more value without a whole lot of deep thought about TZs - they just set a few enums or clicked

something in a wizard that did it for them. Meanwhile, developers who know what they are doing can work with things

themselves.

**

"
>>Just because someone makes up a new time zone for Utah does not mean that everyone immediately and automatically has to

>>adopt it.
>
>If the government changes the time zone on Utah, EVERYONE will adopt and use it. Yes, if some random person does this, no

>one would care, but if our government changes it. It will make a difference. We know our governments changes time zone,

>Australia is doing it, USA is doing it ...etc.
"

Sure, but then one county in Utah might decide against it for whatever reason, with half of the people there going along and

half not. This year, Guatemala arbitrarily decided to implement DST (they had been fixed on UTC-6). So, within a month or

two, they moved from UTC-6 to UTC-5. Many people living in certain villages simply did not respect this change for many

reasons (some called it "devil time"). Then again, those people don't typically use Windows or .NET, so perhaps it's

irrelevant to the BCL team. But something interesting is that, AFAIK, there is no OS patch for this one-year DST for

Guatemala, or the other countries that soon sorta followed suit (they picked different days to revert) -- at least, I haven't

seen anything on Windows update about it, and my time zone list looks the same. Not sure exactly what this means to BCL

either. If it's not in the timezone DB, then it doesn't exist?

Anyways, my bottom line is, please please please ensure that by default, devs must specify what their intent is. If there is

some awesome thing that BCL comes up with that just magically deals with time zones, then make us explicitly opt-in to that.

Also, I just saw the new comments -- the "DateTimeZone" class -- that would just be like Time Zone Info, right? It's not a different class to store datetime in (that'd be confusing and difficult)?

Thanks a lot!
-Michael

re: Designing "Time Zone conversions"

Oren Novotny — Thu, 20 Jul 2006 01:21:39 GMT

Sorry, I was unclear in my last comment -- extending the existing DateTime class is preferable to creating a new class since DateTime is already in wide use and it would be a huge effort to replace one type with the other everywhere.

re: Designing "Time Zone conversions"

Oren Novotny — Thu, 20 Jul 2006 01:17:33 GMT

One thing that would be very helpful would be if you could release a shared-source implementation of these new DateTimeZone classes so that we can start using them sooner rather than later.

Many of us are dealing with these issues regularly and we'd rather not have to wait a long time until a BCL 3 is officially released.

Another thing -- if you're going to create a new DateTimeZone class rather than extend the existing DateTime (which would be preferable considering how many places DateTime is used), the new DateTimeZone class should have implicit conversion operators for DateTime. That would enable a more seamless migration from one type to the other. Since DateTime really stores its value as ticks from some constant UTC time, it should be possible to convert seamlessly.

As far as some of your comments regarding where to store time zone rules, I think that it's a fair trade-off to rely on the local system having an up-to-date conversion table. That way you wouldn't have to store the rules on the type thereby making it incredibly huge.

In a majority of the systems that need time zone conversion it's because we're exchanging data with a remote system. Almost by definition that means both systems are on a network and that means they're able to get updates.

--Oren

re: Designing &quot;Time Zone conversions&quot;

KathyKam [MSFT] — Wed, 19 Jul 2006 00:20:01 GMT

Hi Michael,

I love discussions! Thanks for the feedback! Let me answer your question, before I dive in..

Why is storing "Pacific Time" not sufficient?

Storing just "PST" is insufficient, because "PST" is simply an ID for you to look up the actual time zone rules. Different machine can have different DB. So your actual time will be different if you only store the ID.

E.g.
Machine A has the following PST rule:
Offset = -8 hours
Daylight saving offset = -7 hours
Transition Start Date: 1st Sunday of April
Transition End Date: Last Sunday of October

Machine B has the following PST rule:
Offset = -8 hours
Daylight saving offset = -7 hours
Transition Start Date: 2nd Sunday of March
Transition End Date: 1st Sunday of Nov

Then.. March 31st 6:00pm (PST) will represent different time for Machine A and Machine B. Conversions between UTC and other time zones will result in different values.

"Physical location has nothing to do with which timezone you choose,"

Physical location has everything to do with which time zone you choose. Our time zones are being differentiated by location! People doesn't care about the time zone they are selecting. They only care about the time of day it is in a particular location. When I call home to Hong Kong, I don't care what time zone they are in. All I care about is that I don't wake my parents up at 3am in the morning. Users want a easy way to deal with time zone.Time zone gives people headache. Even the best of us! :) The challenge is in how much we encapsulate and how much flexibility we allow our users to have. Do our developers need to know about the actual rule changes? How much flexibility do we give them? Since we're the BCL, and the "B" really stands for "broad variety of users". This is the design challenge I am trying to highlight in this post.

Just because someone makes up a new time zone for Utah does not mean that everyone immediately and automatically has to adopt it.

If the government changes the time zone on Utah, EVERYONE will adopt and use it. Yes, if some random person does this, no one would care, but if our government changes it. It will make a difference. We know our governments changes time zone, Australia is doing it, USA is doing it ...etc.

What do you think?

Cheers,

Kathy

Designing "Time Zone conversions"

Kathy Kam Designing Time Zone conversions | debt settlement program

Kathy Kam Designing Time Zone conversions | patio set

pacific standard timezone conversion

re: Designing "Time Zone conversions"

Is modifying System.DateTime reasonable for a Time Zone/Offset aware DateTime object?

re: Designing "Time Zone conversions"

re: Designing "Time Zone conversions"

re: Designing "Time Zone conversions"

re: Designing "Time Zone conversions"

re: Designing &amp;quot;Time Zone conversions&amp;quot;

re: Designing "Time Zone conversions"