Thread overview
[Issue 13592] std.datetime fails its unittests on Windows 7 - no Belarus Standard Time?
Oct 09, 2014
Jonathan M Davis
Oct 09, 2014
Jonathan M Davis
Oct 19, 2014
Sobirari Muhomori
Oct 20, 2014
Jonathan M Davis
Oct 20, 2014
Jonathan M Davis
October 09, 2014
https://issues.dlang.org/show_bug.cgi?id=13592

Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com

--- Comment #1 from Jonathan M Davis <jmdavisProg@gmx.com> ---
*sigh* It's too bad that Microsoft won't just use the same timezone information as everyone else. But since they don't, this same problem will pop up every time that Microsoft does a timezone update that adds a timezone or changes the name of one. It could be avoided by getting rid of the tests that fail because of it, but then we wouldn't catch the problem and fix it. So, it sucks, but as long as MS insists on doing it's own thing, we're pretty much stuck. bleh.

Oh well. Such is life. I'll have a pull request up with a fix for this shortly.

--
October 09, 2014
https://issues.dlang.org/show_bug.cgi?id=13592

--- Comment #2 from Jonathan M Davis <jmdavisProg@gmx.com> ---
https://github.com/D-Programming-Language/phobos/pull/2598

--
October 19, 2014
https://issues.dlang.org/show_bug.cgi?id=13592

--- Comment #3 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
What these time zone failures mean? Will it fail in application code as well? Will applications stop working on next time zone update?

--
October 20, 2014
https://issues.dlang.org/show_bug.cgi?id=13592

--- Comment #4 from Jonathan M Davis <jmdavisProg@gmx.com> ---
(In reply to Sobirari Muhomori from comment #3)
> What these time zone failures mean? Will it fail in application code as well? Will applications stop working on next time zone update?

If you're using specific time zone names, and MS changes the names on you, then yes, they could break application code. I've tried to make it so that we'll be able to deal with windows boxes that aren't properly updated, but there's only so much that I can do when MS keeps changing the time zone names and their names rather than having a sane city-based system like the TZ database has.

The unit tests keep failing whenever MS changes the time zone names, because the unit tests are making sure that all of the Windows time zone names on the system are covered by the functions that convert to and from the TZ database names and the Windows time zone names.

I'm increasingly inclined to just deprecate the ability to translate the TZ database names to/from the Windows time zone names, and require that users deal with the problem themselves, or (even better) provide the TZ database files with their windows programs if they want to explicitly use time zones other than the local one. It's causing us problems whenever MS updates, and most folks don't need that functionality (and those who do need to be aware of the possibility of breakage on Windows updates if they're relying on specific time zone names).

Regardless, this only affects folks who are using WindowsTimeZone, which you'd only use if you were trying to get times for time zones other than the local one or UTC on a Windows box. So, most folks are unaffected.

--
October 20, 2014
https://issues.dlang.org/show_bug.cgi?id=13592

Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--