The BCL Team has been spending a lot of time investigating on how to provide richer support for Time Zones. As the PM who owns System.DateTime, I am tasked with figuring out the scenarios that are important for our developers whose customers needs to deal with the changing of time zones.
One of the most requested feature from our customers was to add the ability to convert from one time zone to another time zone. This is a relatively straight forward request, but things are never as easy as it seems. You would expect doing a conversion like this will require an API along the lines of:
DateTime TimeZone.Convert(DateTime dateTime, TimeZone src, TimeZone dest);
By just reading this, it seems quite straight forward. Given a certain DateTime, you convert it from the source time zone to the destination time zone.
E.g. My dog, Mojo, was born in Kenmore, WA (Pacific Standard Time - PST) on April 15th 2006 at 2am. If I want to find out Mojo's birth time in New York, NY (Eastern Standard Time - EST) I will need to do something like this:
// My dog's birthdayDateTime mojoBirthTime = new DateTime(2003, 4, 15, 2, 0, 0); DateTime mojoNYBirthTime = TimeZone.Convert(mojoBirthTime, PST, EST);
You would expect, mojoNYBirthTime to be "April 15th 2003, 5:00am". Simple!
However, haven't we forgotten about the DateTime.Kind enum?? What if we did this:
DateTime mojoBirthTime = new DateTime(2003, 4, 15, 2, 0, 0); DateTime mojoLocal = new DateTime(mojoBirthTime.Ticks, DateTimeKind.Local);DateTime mojoEstBirthTime = TimeZone.Convert(mojoLocal, PST, EST);
If my machine's local time zone is in Mountain Time (MST), then should I convert from PST, MST or what??? Similarly, what if:
DateTime mojoBirthday = new DateTime(2003, 4, 15, 2, 0, 0); DateTime mojoLocal = new DateTime(mojoBirthday.Ticks, DateTimeKind.Utc);DateTime mojoEstBirthday = TimeZone.Convert(mojoLocal, PST, EST);
Ah.. something as simple as a time zone to time zone convert doesn't look so simple anymore. Should we respect DateTime.Kind, should we respect the passed in time zone or should we throw in this case? Things are never as simple as it seems. Does it happen to you too?
Additionally, with the US Time Zone changes coming into effect in 2007, (Per Engergy Policy Act of 2005: "Daylight Saving Time will start on the second sunday in March instead of the first Sunday in April, and will end on the first Sunday in Novemenber instead of the last Sunday of October") the need for supporting changing time zones rules becomes more apparant. Though US is only experiencing these changes for the first time since 1986, many other countries (like Isreal) have to deal with daylight savings changes on a yearly basis. Vista has introduced the "Dynamic Time Zone Information" API to handle the changing of daylight saving time, in the managed code side of things, we are looking into ways of adding support.
What do you think of Vista's DYNAMIC_TIME_ZONE_INFORMATION API?