https://issues.dlang.org/show_bug.cgi?id=13592
--- Comment #4 from Jonathan M Davis <[email protected]> --- (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. --
