On 03/07/17 16:59, Jonathan M Davis via Digitalmars-d wrote:
1. The functions for converting to and from a timezone take a struct containing information about what that timezone is - including the DST switches. The way that MS did that orginally involved specifying something like the nth instance of the xth day of the week in a particular month (e.g. the first Sunday in April), and that was for all time, as if time zones never changed when they have DST switches - which of course, doesn't work well for many timezones (there's even a wikipedia article on how Windows kept having the time wrong in Israel because of this). MS didn't bother to fix this until the US and Canada changed when DST was going to be starting in 2007.
Considering that wikipedia article used to link to *my* site for how to fix this, I think I safely say "I know".
In fact, MS used to link to my site for a solution, which hilarious, because by "my site", I mean "my company", which was named "Lingnu Open Source Consulting Ltd.".
Without that change, you end up using the old DST rules, and last time I checked, wine had not made that change. So, if you used the old functions (which IIRC, std.datetime does, because at the time it was written, we were trying to support Windows XP), and you use wine, then DST will be wrong for some dates which would be correct on Windows.
Sounds easy enough to both create a unit test and fix. Let's see if Alexandre will take my patches after so many years[1] :-).
2. The time zone conversion stuff in Windows is unfortunately defined in the registry, and AFAIK, the only way to look up an arbitrary time zone instead of using local time or UTC is to read in the information from the registry and fill in the aforementioned struct with time zone information with that information. The time zones are listed in the registry based on the English names that MS uses - e.g. "Pacific Standard Time" is what they use for the Pacific time zone (though it has both the standard time and DST information in there). Pretty much every other OS uses the time zone database for their time zone information, and that uses major cities to distinguish time zones (e.g. the Pacific time zone would be "America/Los_Angeles"), not something like "Pacific Standard Time". wine chose to use the time zone database names like "America/Los_Angeles" in their registry instead of the names that Windows uses
That one sounds like potentially harder to fix. I'll ask on the wine lists and see if anything comes up.
Also, note that even if I submit patches, and they get merged, it's around a year until major distributions pick that up.
Still, better late than never. Shachar 1 - By which I mean that maybe, after so many years, he now will.
