[Issue 13592] std.datetime fails its unittests on Windows 7 - no Belarus Standard Time?

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13592

--- Comment #4 from Jonathan M Davis <jmdavisProg at 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.

--