Search Form
Syndication
Administrivia

Results of the 'Time Zone Scenario Feedback' feared

Sorting it all Out
Michael Kaplan's random stuff of dubious value
Be sure to read the disclaimer here first!
MSDN Blogs > Sorting it all Out > Results of the 'Time Zone Scenario Feedback' feared

Results of the 'Time Zone Scenario Feedback' feared

7 Jul 2006 3:01 AM
  • Comments 12

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

Now I have mentioned before in connection with this hole issue about how Time zones make me cringe.

As I look at the potential list of features that Anthony has listed, I have not been cured of the cringe problem; if anything I am more nervous. :-(

My opinion, for what it is worth:

  • NO functionality to affect the machine settings should be integrated into the BCL. These are settings that have huge potential affects on applications even in their current form (like I mentioned here); if all it takes is a few lines of managed code then the platform is being opened up to a potential nightmare from which schedules may never fully recover;
  • Special care should be taken to make sure that Win32 settings and its UI is extended, and that its is not supplanted -- the vast majority of users still have that UI and its consequences to deal with in user and kernel mode; sloppiness here will lead to problems like "managed app brings down AD install" and worse;
  • Slowing down is probably pretty important at this point -- developers do not tend to answer questions like "Do you want feature X added?" with anything other than YES. Any full steam ahead feedback push is guaranteed to generate the wrong answers here.

My cringing is mainly because there seems to be a strong desire to make sure that all of the features that can be added might be, rather than a cautious approach that perhaps slowly works to add features so there is time to assess the consequences more fully, for both users and developers.

I still have hopes that the right thing will happen here, but when the wish list is put in front of everyone for them to rate, it makes it sound like there may be some wrongness if the ratings are high enough for this most requested feature.... :-(

 

This post brought to you by a (U+0061, a.k.a. LATIN SMALL LETTER A)

,
Comment on the blather
Leave a Comment
  • Please add 3 and 2 and type the answer here:
  • Post
Blog - Comment List
Comments
  • Mihai
    7 Jul 2006 4:38 AM
    Why not solve easier things, like for instace not having Windows change my time without asking when DST changes. I boot multiple partitions, sometimes multiple hdd (with various language OS) and each one changes my clock, so sometime I end up with a 5-6 hours offset.

    Why not store a flag in CMOS saying "is DST already!"

    Especially that the flag is in CMOS for about 20 years now :-)
    (see CMOS layout, bit 0 of RTC status register B (0x0b))
    Don't you think is time for Windows to learn about it and use it?

    And no, is not about i18n, and not in you backyard, I know :-)
  • 7 Jul 2006 8:30 AM
    Hi Mihai,

    These are all suggestions for the OS (and the hardware) -- not ones that can be done in the BCL, either. :-)

    I think that means you agree with me!
  • Mihai
    7 Jul 2006 4:20 PM
    I think I agree with you.
    All features sound cool, if they can get them right, BUT:

    1. Some of the features are impossible to get right with the current info
    ie when time goes back because the DST changes, there is a one hour interval when you cannot say what time really is, unless you also get the info that DST is in effect or not)

    2. Historical time zone is kind half the story, historical calendar info would also be nice (but a pain to do for Hijri)

    3. Some of the features belong in Win32

    4. Stuff like "2006-07-06T08:49:00+05:00" has no time zone info, so there is no data about what DST rules apply

    In general, I agree with your arguments in "Time zones make me cringe."
    I would like to see the tough problems solved by the OS, but better nothing than a buggy solution.
  • Ruben
    8 Jul 2006 5:11 PM
    Well, part of the problem is that they've been postponing this stuff for ages (.NET or OS, take your pick). Many applications actually need a little more than just the current time zone. Even if it's just enumerating the existing time zones (and using them!)

    And forcing everybody to come up with their own implementation seems silly: in practice, that's even more buggy!

    In fact, I don't really know where the OS should come in. Is there a process-level TZ switch? If not, then the entire argument is moot. The OS provides basic time zones, and each process gets the default time zone. You want to use another? Then use it. Only your .NET TZ-aware functions would be the wiser.

    Same thing happens with .NET's CultureInfo. My XP box has no notion of 'custom' regional settings. Except my .NET 2.0 apps, that is.

    So regardless of the course taken, _something_ is better than nothing.

    (Unless, Michael, your greatest fear comes out, and they goof up monumentally. I truly hope not.)

    Oh, and they shouldn't allow any API to change the user's time zone, or the preinstalled time zones. There's only one entity that should be allowed to change the user's time zone, and that is the user. And there's only one entity that should change the preinstalled time zones, and that is MS.

    (And they should, for once. Even if it's just for the Common Wealth Games in Australia. For some reason, my time zone settings no longer line up with the official rules in Australia, because I don't live in Australia; some of my friends might, thankyouverymuch.)
  • Mihai
    8 Jul 2006 7:10 PM
    <<Well, part of the problem is that they've been postponing this stuff for ages (.NET or OS, take your pick).>>

    I would definitely want the OS to do it, and do it right, instead of each programmer out there (including me) trying and getting it wrong :-)

    But I would like to make sure is done correctly, and at the right level.

    I know enough .NET, but most of my programming is still Win32, and I would hate to see this functionality added to .NET and not to Win32.

    And I see no technical reason why do it .NET only.
  • 9 Jul 2006 3:44 PM
    User feedback is a good thing.  Slavish devotion to user feedback is bad, but have faith in the judgment of the team.

    > Stuff like "2006-07-06T08:49:00+05:00" has no time zone info, so there is no data about what DST rules apply

    There are several problems to be solved.
    The string you mention does uniquely identify a particular instant in time, which is (IMHO) the most important of the problems.  Nothing can possibly work if this is broken.

    Adding DST rules is best done at the locale level, and requires constant vigilance as the whims of politicians play havoc with the scientific basis of time measurement.

    It is, first and foremost, important to know "When Something Happens."
    It is /secondarily/ of import to know "How to Spell That Instant."
    It is only thirdly of importance to support pseudo-cyclic intervals like "Every Sunday at 2:30 AM, 'local time'"
  • Mihai
    10 Jul 2006 6:27 PM
    <<Stuff like "2006-07-06T08:49:00+05:00" has no time zone info, so there is no data about what DST rules apply>>

    <<The string you mention does uniquely identify a particular instant in time, which is (IMHO) the most important of the problems.  Nothing can possibly work if this is broken. >>

    This is the main problem: the strings like the one above DO NOT uniquely identify a particular instant in time.

    Problem 1: same string can represent two different times
    Ex: "2006-10-29T01:30:00-08:00"
    And let's say we know we are in CA (not part of the info in string)
    Since "in fall, clocks fall back from 1:59 a.m. to 1:00 a.m", it is not possible to determine if "this" 1:30 is before or after the DST started. That night you have 1:30 twice.

    Problem 2: time zone & DST rules are not part of the string
    Ex: "2006-07-06T08:49:00-07:00"
    Is there a DST in effect or not? If I am in Arizona, there is no DST.
    But the Navajo Nation ubserves DST even in Arizona.
    And there is also nothing telling us this is about Arizona.
    Ex: "2006-07-06T08:49:00-05:00"
    Is there a DST in effect or not? I don't even know if I am in NY or somewhere in South America.

    So yes, you can parse the string, but have no clue how to convert to UTC, because there is no time zone info. -07:00 is not enough to tell you where you are.
  • 10 Jul 2006 7:09 PM
    There is also the difference between Win32 and .NET to consider here, in addition to the points Mihai is making. :-)
  • 10 Jul 2006 8:15 PM
    > "2006-10-29T01:30:00-08:00"
    > And let's say we know we are in CA (not part of the info in string)
    > Since "in fall, clocks fall back from 1:59 a.m. to 1:00 a.m", it is not possible to determine if
    > "this" 1:30 is before or after the DST started. That night you have 1:30 twice.

    Not true, when DST is in effect, your offset from UTC changes. In Sydney, our "normal" UTC offset is +10 but with daylight savings it's +11.

    So 1:30 before daylight savings finished would be "2006-04-02T02:30:00+11", and "2006-04-02T02:30:00+10" is the 1:30 after it finished.

    You have to remember that when daylight savings time is in effect, you're actully in a different timezone to when it is not in effect. So when it is not in effect, I am in AEST, which is +10 from UTC. And when it is in effect, I am in AEDT, which is +11 from UTC.

    So, "2006-04-02T02:30:00+11" really DOES represent a single instance in time. But that is not the problem - the problem is what you mentioned: it doesn't actually tell you WHERE that time was taken. It doesn't tell you whether you're in Sydney during DST, or in Vanuatu (which is where I wish I was!) in standard time.
  • Richard
    13 Jul 2006 11:18 AM
    > NO functionality to affect the machine settings should be integrated into the BCL.

    I agree... because effect of exposing this to application code is just going to create pain.

    An example from the world of VBA: http://thedailywtf.com/forums/thread/81275.aspx
  • Sorting It All Out
    13 Feb 2007 4:59 PM

    I have posted previously in entries like Sometimes what a person really wants is a LACK of size about

  • Sorting it all Out
    29 Jun 2008 1:57 PM

    Kim Gräsman asks via the Contact link: Subject: GetTimeZoneInformation changed on XP? Hi Michael, I haven't

Page 1 of 1 (12 items)
MSDN Blogs > Sorting it all Out > Results of the 'Time Zone Scenario Feedback' feared