Bug 13592 – std.datetime fails its unittests on Windows 7 - no Belarus Standard Time?

C:phobos>..\dmd -unittest -main std\datetime c:cbx\mars\druntime\import\core\atomic.d(391): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not c:\cbx\mars\druntime\import\core\atomic.d(245): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not C:\cbx\mars\phobos>datetime core.exception.AssertError@std\datetime.d(29519): TZName which failed: Belarus Standard Time ---------------- 0x0056F78D 0x00567D57 0x00574B8F 0x00571163 0x00567EDB 0x7699338A in BaseThreadInitThunk 0x77EA9F72 in RtlInitializeExceptionChain 0x77EA9F45 in RtlInitializeExceptionChain It works on Linux and OSX. Marked as major because it's very annoying to have Phobos fail its unittests. Likely related to https://issues.dlang.org/show_bug.cgi?id=13313

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

What these time zone failures mean? Will it fail in application code as well? Will applications stop working on next time zone update?

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