Time Zone Scenario Feedback Wanted [Anthony Moore]

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

zibb — Tue, 01 Aug 2006 12:58:46 GMT

1. 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

Designing "Time Zone conversions"

Kathy Kam — Fri, 14 Jul 2006 01:42:17 GMT

The BCL Team has been spending a lot of time investigating on how to provide richer support for Time...

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

Marc Brooks — Mon, 10 Jul 2006 22:19:04 GMT

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

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

vincent schol — Mon, 10 Jul 2006 14:28:44 GMT

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.

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

Ruben — Sat, 08 Jul 2006 23:00:29 GMT

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.

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

Clay_Keller — Sat, 08 Jul 2006 00:00:18 GMT

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.

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

Michael Vanhoutte — Fri, 07 Jul 2006 21:19:46 GMT

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.

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

Michael Giagnocavo — Fri, 07 Jul 2006 19:13:00 GMT

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")?

Results of the 'Time Zone Scenario Feedback' feared

Sorting It All Out — Fri, 07 Jul 2006 15:20:40 GMT

Over on the BCLTeam blog, Anthony Moore has posted Time Zone Scenario Feedback Wanted.
Now I have mentioned...

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

TAG — Fri, 07 Jul 2006 14:27:50 GMT

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).

Time Zone Scenario Feedback Wanted [Anthony Moore]

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

Designing &quot;Time Zone conversions&quot;

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

Results of the 'Time Zone Scenario Feedback' feared

re: Time Zone Scenario Feedback Wanted [Anthony Moore]

Designing "Time Zone conversions"