Time Zones in the .NET Framework [Anthony Moore]
The single most requested individual feature for the Base Class Libraries that has not been delivered yet is for support for Time Zones other than Local and UTC. This is a feature we are actively exploring for the next release of the .NET Framework.
To tide people over, we recently released an updated sample that supports the following scenarios:
- Enumeration of Time Zones from the Windows Registry.
- Conversion of a DateTime instance between Time Zones.
The sample can be downloaded from here:
The sample is similar to one that was available in the SDK previously. However, the previous sample did not adjust conversions for Daylight Savings Time. This sample does account for Daylight Savings time in the same way that the DateTime class itself accounts for it for local times. In fact, we used some of the same testing code to verify it.
For those of you that need Time Zone support, we are definitely interested in finding out what your scenarios are. Here are some examples of scenarios under discussion:
- Support for retrieving and changing the Local Time Zone.
- The ability to serialize Time Zone information, for example in the case of storing the information for a recurring meeting.
- Support for Time Zones with rules that change from year to year.
- Ability to pick up time zone data from the operating system.
- Ability to add a custom time zone.
- A data type with a DateTime and a Time Zone offset.
People are often not specific when they request Time Zone support, so if this is something you need, if you can clarify the specific scenarios that are valuable, it will help us build a better product.
Comments
Anonymous
April 03, 2006
The comment has been removedAnonymous
April 03, 2006
My vote is for covering these areas, in order of preference (which you listed, so I'll just steal your words and add some comments):
- Support for Time Zones with rules that change from year to year
---- hopefully for say, given a time zone and a date anywhere from the past 100 years and going forward, you could tell me what the offset is (with daylight savings taken into consideration, obviously)
- The ability to serialize Time Zone information, for example in the case of storing the information for a recurring meeting
- A data type with a DateTime and a Time Zone offsetAnonymous
April 03, 2006
The comment has been removedAnonymous
April 03, 2006
Everything that you've mentioned would be cool, but honestly... the ability to convert a UTC date to any TimeZone would already cover 99% of my needs.
Of course, the DateTime structure should have some knowledge of which TimeZone it is in, but it shouldn't be a huge problem if this proves to be too difficult. The work-around would be to ensure that one always moves dates around in UTC and only converts them to a specific TimeZone for display purposes. That does come without a performance cost of course, but it would be doable.
The ability to add custom timezones using code or configuration files would be nice as well.
By the way, on a sidenote: finally, finally, finally :-)Anonymous
April 03, 2006
I did talk about a particular time zone issue earlier today....
And I see that Anthony posted about...Anonymous
April 04, 2006
I remember I was utterly surprised about System.DateTime having no support for timezones.
I consider the original timezone offset being part of the precision of a date/time value.
I'd want a future DateTime data type to correctly support round-tripping (ToString->[Try]Parse in a different TZ) almost all date/time formats found on the web today, including but not limited to the formats used by HTTP/RSS/RDF/ATOM and XML Schema.
There's a nice write-up at http://www.hackcraft.net/web/datetime/.
But then again, the large cross-section with localization, e.g. names of days, months, time zones, might make the implementation a real nightmare.Anonymous
April 04, 2006
Somewhat related:
Using System.Diagnostic.EventLog.WriteEntry(source, message)
...if I am writing messages using a common source, and using the static method, and not concerning myself with initing, opening, closing endIniting the source, the dates of the log entries jump forward one hour when the time changes.
This is a minor concern for our application, but if there was some more information on exactly what is causing this, I would be interested.
On another topic, I would have thought that
DateTime dt1 = DateTime.Now().ToUniniversalTime()
would equal
DateTime dt2 = dt1.ToUniversalTime()
...but it doesn't.
As Michael Kaplan echoes Raymond Chen, the complexities here are unintuitive and the problems vary by domain. Good luck in getting this right AND making it interoperate with legacy code.Anonymous
April 04, 2006
People are often not specific when they request Time Zone support
Please support the tz database syntax
http://www.twinsun.com/tz/tz-link.htm
ftp://elsie.nci.nih.gov/pub/Anonymous
April 04, 2006
We’ve taken a break on blogging since shipping Whidbey. As our team is gearing up for Orcas, we decided...Anonymous
April 07, 2006
This will be a welcome addition to the Framework. I'm the IT Director for a major relocation company and our business is going global in a big way right now.
Increased support for time zones would really be a nice touch and would save us money (since my programmers wouldn't have to write or support the code). In the meantime, I'll take a look at that demo app.Anonymous
April 08, 2006
One scenario to consider is converting a time from say UTC to another timezone in the past. Sounds simple, but what happens if the zone that you're converting to has in the interim changed whether they support DST or even their timezone?
This happens, and would required a full tracking of each timezone legislative change. In the US, we've modified the date of when DST starts/stops on several occassions and it's up for change again. Within the US, parts of Indiana
I've always thought that the "local" timezone of the participant of the Transaction needs to be recorded alongside the "server" timestamp. This gives me a persisted view of what the situation was at the time of transaction. If I only have 1 date to work from and it's in the past, there's no guarantee that it will be the correct TZ conversion unless the underlying libraries keep track of all the law updates per timezone and location.Anonymous
April 09, 2006
Matthew van Eerde (Maurits) suggests you "support the tz database syntax" and, without elaborating, provides links to the tz database Web page.
One cannot write software that correctly handles world time zones and daylight saving times (summer times) without a complete, well-maintained database of those data, which are Byzantine. The only such database that exists and can be called authoritative is the tz database, commonly refered to as the Olson database. As the Web page explains, "This database (often called tz or zoneinfo) is used by several implementations, including the GNU C Library used in GNU/Linux, FreeBSD, NetBSD, OpenBSD, Cygwin, DJGPP, HP-UX, IRIX, Mac OS X, OpenVMS, Solaris, Tru64, and UnixWare." In other words, almost everything but Windows.
The C# code posted here includes comments like this: "In southern hemisphere, the daylight saving time starts later in the year, and ends in the beginning of next year. Note, the summer in the southern hemisphere begins late in the year." And this: "In northern hemisphere, the daylight saving time starts in the middle of the year." Even if there's some strange truth behind these oddly-worded observations, they have no meaningful relationship to time zone boundaries or daylight saving time conventions. Nothing time zone-wise happens universally in either hemisphere. I'm not sure what the code is attempting to do, or how.Anonymous
April 12, 2006
Thanks very much everyone for this great feedback. We can apply this directly to decisions about which scenarios within the feature to do and how to prioritize them.
In particular, it is interesting to see the priority placed on serializing a set of time zone data, and making the system extensible enough to support something like Olson.
Responses to some specific feedback:
>>On another topic, I would have thought that
>>DateTime dt1 = DateTime.Now().ToUniniversalTime()
>> would equal
>> DateTime dt2 = dt1.ToUniversalTime()
That would equal DateTime.UtcNow, but the call to DateTime.Now clobbers the original date.
>> The C# code posted here includes comments like this: "In southern hemisphere, the daylight saving time starts later in the year, and ends in the beginning of next year. Note, the summer in the southern hemisphere begins late in the year."
This comment is merely indicating that you need to account for situations where DST starts later in the year and finishes early in the next year, so you will notice the range comparison needs to differ. This usually happens in the Southern hemisphere, but this is logic based on the data and not a heuristic or guess.
Thanks again for your feedback on this topic. Please keep it coming to help us build a better feature!Anonymous
April 19, 2006
Thanks for the reply.
I understand what happens - DateTime has no indication of TimeZone, so it always assumes that "ToUniversalTime() is a local timezone and simply applies the offset.
Perhaps a better example to show what I mean is that:
DateTime.UtcNow != DateTime.UtcNow.ToUniversalTime()
// Even though it is already Universal time, it still re-evaluates. This is obvious if you know the limitations of the class, but not obvious from the method name to a casual user. No big deal, just thought I would point out that in actual code I was writing, I tried converting things to UTC for comparisons, not concerning myself if it had already been done, and it turned out, obviously, incorrect.Anonymous
April 19, 2006
The comment has been removedAnonymous
April 26, 2006
The ability to have a site hosted on a server (say in the us) return the date/time for a specifed time zone (including daylight saving time)
thanksAnonymous
April 27, 2006
aAnonymous
May 05, 2006
The following links to .NET resources have been collated over time with the assistance of colleagues. ...Anonymous
January 25, 2008
PingBack from http://softwareinformation.247blogging.info/bcl-team-blog-exploring-windows-time-zones-with-systemtimezoneinfo/Anonymous
June 09, 2009
PingBack from http://quickdietsite.info/story.php?id=13358