Time Zone Scenario Feedback Wanted [Anthony Moore]

Time Zone Scenario Feedback Wanted [Anthony Moore]

  • Comments 17

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.
  • 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));
    }
  • "8. Helper functions allowing for some simple conversions to happen in a single line of code.  e.g. TimeZone.Convert(time, “Pacific”, “Eastern”)." This is a great idea.
  • Far too often, many public-facing website will display a date and &quot;time&quot; about something&#160;- without at least displaying&#160;a reference to a&#160;timezone. How useful is that?

    I mainly develop ...
  • 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.
  • In the last couple of years, these are the things that I at could have used at least one or twice:
    1. Creating a custom time zone, i.e. programmatically creating a time zone other than the default set of time zones on the machine.
    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”.

    I would consider 1, 8 and 9 must haves. 7 a nice to have. Some remarks:

    "Supporting an ambient time zone setting at the level of the thread or process."
    I would find this to be particularly useful when used within ASP.NET where you could have a different timezone for every HTTP request being processed.

    "Helper functions allowing for some simple conversions to happen in a single line of code."
    That would be a fantastic feature. However, I would not implement it using string arguments for the Timezones, but I would suggest the same thing as Lt does.
    Something like TimeZone.Convert(time, Timezone1, Timezone2) would make it much easier to use with custom timezones. Otherwise, one would have to persist a custom time zone in one way or another before you could use it. To make it a bit more user-friendly, you could perhaps do something like you did with the Encoding-classes. Their, one can do 'new UTF8Encoding()', but there is a shortcut Encoding.UTF8. Perhaps you can provide some shortcuts like TimeZone.Pacific and TimeZone.Eastern as well. (don't know if you're willing/able to hard-coded these timezones as static properties though).
  • 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.
  • The ability to control dataset serialization behaviour for timezone would be something I could have used.
  • 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).

  • Over on the BCLTeam blog, Anthony Moore has posted Time Zone Scenario Feedback Wanted.
    Now I have mentioned...
  • 1. 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")?
  • 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.
  • I think you should just let 3rd parties offer most of this functionality. It is fairly easy to implement most of this with managed code algorithms and open source .net code already exists for much of this.

    One of the problems is that time zones are not always agreed upon by various regions and some regions/countries don't necessarily live by the standard timezone definitions. So if you do provide these standard functions, you would surely need to provide a method to create custom zones.

    The following should be provided, because the only way to do it now is to use interop and Win32 API calls.

    -> Supporting changing the machine’s current time zone.

  • Also, consider

    1) not reinventing the wheel; look at e.g., Java, and the tz database (http://www.twinsun.com/tz/tz-link.htm).

    2) supporting invariant 'names' for time zones, like the ISO country and language codes. Things like the tz database's Europe/Paris and America/Los_Angeles (such as Java does).

    3) not supporting things like EST universally. Maybe only within a CultureInfo context of en-US, or the right RegionInfo. Abbreviation like EST are not used by Americans alone!

    4) not supporting things like TimeZone.Eastern. Again, the world does not consist of Americans alone. The Eastern part of my country has the same timezone as the middle and the Western part, for example. TimeZone.GetSpecificTimeZone("America/New_York") should suffice.

    5) custom time zones that can be stored on the machine, like CultureInfo. This would allow for time zones you didn't think of. and let's be honest: no-one think of everything.

    6) updating the central repository when required. So when Australia decides to alter their time zone for the Olympics, my programs don't use the wrong time zone info when comunicating with some system down under. In other words: don't let .NET behave as poorly as Windows.
  • 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.

  • 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
Page 1 of 2 (17 items) 12