Time Zone Scenario Feedback Wanted [Anthony Moore]
The Base Class Libraries is exploring scenarios related to Time Zone support and we are very likely to have a solution for this problem in the next release. We have already received a lot of great feedback from an earlier post. There are several high level scenarios where we have already received considerable feedback that they are in high demand and would be broadly used:
- Enumerating a set of time zones
- Converting between a set of time zones
- Serializing and de-serializing a time zone
- Having a DateTime with a UTC offset baked in.
- Supporting historical time zone conversions where the daylight savings rules can change from year to year.
A less clear question is about more secondary time zone scenarios. We really can’t have too much customer feedback about these to help us build the best feature possible. We would be interested in hearing feedback about these more secondary scenarios:
1. Creating a custom time zone, i.e. programmatically creating a time zone other than the default set of time zones on the machine.
2. Writing a custom time zone back permanently to the default set of time zones on the machine.
3. Creating a copy of a time zone with daylight saving time turned off.
4. Functions to ask whether a local time falls into an undefined or ambiguous/overlapped region caused by winding the clock back or forward for Daylight Savings Time boundaries.
5. Supporting historical time zones where the base offset can change from year to year.
6. Supporting changing the machine’s current time zone.
7. Supporting an ambient time zone setting at the level of the thread or process.
8. Helper functions allowing for some simple conversions to happen in a single line of code. e.g. TimeZone.Convert(time, “Pacific”, “Eastern”).
9. Parsing and formatting of DateTimes with embedded time zone acronyms, e.g. “PST”, “EDT”.
Another thing we would be interested in hearing about are TimeZone related scenarios that you feel are important but are not on either of these lists.
It should be made clear that we cannot necessarily provide all of these even if they are in high demand, as there are non-obvious technical difficulties with some of these, and we always have to balance demand for these against the opportunity cost of doing other BCL feature work. However, the more information we have about what people would actually need the better solution we can provide.
We would be open to information in any form, e.g. ranking the secondary scenarios in order, indicating a “yes/no/maybe” on whether the would be used by your, or calling out scenarios we should explicitly not be supporting for one reason or another. Detailed discussion of scenarios is also most welcome. Any feedback would be much appreciated and will help us deliver a better product.
Comments
- Anonymous
July 05, 2006
Ranked in reverse order of importance to me "[9]=least, [1]=most", along with my MoSCoW rating
[1] "9. Parsing / formatting DateTime" (M)
[2] "8. Named time zone conversion" (M)
[3] "7. Ambient thread time zone" (M)
[4] "3. Copy with DST turns off" (M)
[5] "4. Ambiguity functions" (S)
[6] "5. Historical time zones" (C)
[7] "6. Change machine time zone" (W)
[8] "1. Create custom time zone" (W)
[9] "2. Write time zone to machine" (W)
In relation to list item 9, it is important to me that the input time zone is preserved across the life of the value:
[TestMethod]
public void PreserveTimeZoneTest()
{
DateTime date = DateTime.Parse("2006-07-06T08:49:00+05:00");
date.AddDays(1);
Assert.AreEqual<string>("2006-07-07T08:49:00+05:00", XmlConvert.ToString(date));
} - Anonymous
July 05, 2006
The comment has been removed - Anonymous
July 06, 2006
Far too often, many public-facing website will display a date and "time" about something - without at least displaying a reference to a timezone. How useful is that?
I mainly develop ... - Anonymous
July 06, 2006
I recently worked on a project where the functionality of Java's Timezone and SimpleTimezone was needed in .NET.
TimeZone.Convert(time, “Pacific”, “Eastern”)
The problem with this is what is Pacific or Eastern? How do they relate to each other, who defines them?
I think it should be more or less like this:
TimeZone.Convert(time, Timezone1, Timezone2)
Timezone1 and Timezone2 should be user defined with DST rules and UTC offset information.
This is the approach we used to solve our problems. We created a custom Timezone class that took in Timezone information. We stored the Timezone information in a database and during runtime constructed the Timezone objects that were needed for conversion.
Our conversion process involves comparing the UTC offset and DST rules of the two Timezones, then applying the offset to the date.
Parsing/Formatting of date/string required a format string as well as the input/output Timezone. The conversion was actually a seperate step in this process.
If there is one update to the System.Timezone class that I think is needed, it would be the ability to create Timezones. - Anonymous
July 06, 2006
The comment has been removed - Anonymous
July 06, 2006
All sounds nice, but some of these are not possible to implement in a reliable manner.
(for instance "Converting between a set of time zones")
The tricky part is when the DST starts/ends.
There is an interval of one hour when you cannot say what time really is, using just date+time+UTC offset. - Anonymous
July 06, 2006
The ability to control dataset serialization behaviour for timezone would be something I could have used. - Anonymous
July 06, 2006
a) Leap seconds !
http://en.wikipedia.org/wiki/Leap_second
b) Old style vs. new style dates.
c) All settings for timezones must not be hardcored - but configuration options (XML/registry - does not matter).
d) DateTime class must store not simply UTC offset - but full timezone reference with DST flag (i.e. standard time vs. daylight one)
e) It must be possible to round-trip all parsing/formatting. All operations like DateTimeZone +- Timespan must keep original timezone name and DateTimeZone - DateTimeZone must support different timezones (as Timespan is neutral). - Anonymous
July 07, 2006
Over on the BCLTeam blog, Anthony Moore has posted Time Zone Scenario Feedback Wanted.
Now I have mentioned... - Anonymous
July 07, 2006
Creating a custom time zone...
// Don't see much need, but wouldn't hurt
2. Writing a custom time zone back permanently...
// I can't see why an app would need to do this. Sounds dangerous to expose this as a supported function.
3. Creating a copy of a time zone with daylight saving time turned off.
// Can't hurt, not sure of the benefit.
4. Functions to ask whether a local time falls into an undefined...
// This would be nice to have.
5. Supporting historical time zones where the base offset can change from year to year.
// Yes, this is important. I want to be able to format any UTC datetime in a local timezone and have it be correct.
6. Supporting changing the machine’s current time zone.
// No, please no.
7. Supporting an ambient time zone setting at the level of the thread or process.
// That sounds anything from slightly confusing to downright evil, depending on what the effect is. Even in a web app, I don't see the usefulness of this, unless it automagically converted every datetime when formatting (assuming the datetimes had UTC offsets baked in). But seeing as people have enough trouble with datetimes as is, making it less implicit (because the thread would have this setting, so it's transparent), seems like it'd open up some pitfalls.
8. Helper functions allowing for some simple conversions ...
// Yes, only with the caveat that the parameters should be timezone objects, not strings.
9. Parsing and formatting of DateTimes with embedded time zone acronyms, e.g. “PST”, “EDT”.
// That'd be useful.
But thanks for finally getting time zone support in!!! When you say next version, is that WinFX (".NET 3")? - Anonymous
July 07, 2006
Now that I've read Michael Giagnocavo remarks about "Supporting an ambient time zone setting at the level of the thread or process" I must change my opinion. It is indeed to dangerous to do this on a thread- or process-level because it could have unintended consequences for other libraries that are also using dates. Especially if this would be supported on a process-level. In ASP.NET for example, one website could accidently change the timezone of another website. Obviously not desired behavior and almost impossible to debug. - Anonymous
July 07, 2006
The comment has been removed - Anonymous
July 08, 2006
The comment has been removed - Anonymous
July 09, 2006
I wrote my own version of the methods ToLocalTime and ToUniversalTime. I treat the Day Light Saving transition hours different than the methods in System.DateTime by forcing the minutes and seconds in a transition hour to zero. This is necessary when dealing with intervals rather than isolated moments.
Consider an interval at march 28 2004 from 02:30:01 till 03:15:00 expressed in local time (Western Europe).When calling System.DateTime.ToUniversalTime this becomes 01:30:01 till 01:15:00. You see that the interval has a negative length in UTC! When calling my own ToUniversalTime this becomes 01:00:00 till 01:15:00. - Anonymous
July 10, 2006
In order of importance:
7, 1, 5, 4, 9, 8 (but use codes shown in 9)
Not worth doing (but if you have time):
2, 3
Don't you DARE:
6 - Anonymous
July 13, 2006
The BCL Team has been spending a lot of time investigating on how to provide richer support for Time... - Anonymous
July 31, 2006
Full compatibility with Unix/Java platform through direct usage of olson database.
2. Recognition of "spring forward" and "fall back" regions. As an example I could give the existing solution - TZ4Net library available at http://www.babiej.demon.nl/Tz4Net/main.htm
Regards,
Zibb