On 03/07/17 15:35, Jonathan M Davis via Digitalmars-d wrote:
> Well, that looks bad, and it really should be working better than that, but
> I would point out that (at least, the last time I checked), wine does not
> behave correctly with regards to some of the date/time stuff, so some of the
> std.datetime tests will fail with wine, and fixing that requires that wine
> start behaving like Windows like it's supposed to.

Do you have specific examples? My Wine hacking days are long behind me, but I'm fairly sure such easy wins would be simple enough fix to get into Wine.

The Wine charter is to be "bug for bug compatible with Windows", so such changes should not have any trouble to make it in, assuming we can supply a test that proves that's the case.

Shachar

On Monday, July 03, 2017 15:43:57 Shachar Shemesh via Digitalmars-d wrote:
> On 03/07/17 15:35, Jonathan M Davis via Digitalmars-d wrote:
> > Well, that looks bad, and it really should be working better than that, but I would point out that (at least, the last time I checked), wine does not behave correctly with regards to some of the date/time stuff, so some of the std.datetime tests will fail with wine, and fixing that requires that wine start behaving like Windows like it's supposed to.
>
> Do you have specific examples? My Wine hacking days are long behind me, but I'm fairly sure such easy wins would be simple enough fix to get into Wine.
>
> The Wine charter is to be "bug for bug compatible with Windows", so such changes should not have any trouble to make it in, assuming we can supply a test that proves that's the case.

Two come to mind:

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.

To fix this for Vista, MS added a new version of these functions which assume that the DST rules are good for a particular year (which still isn't entirely correct but at least is _much_ closer), but they couldn't retroactively add that to existing programs. Anything using the old functions would still be broken. Their solution seems to have been to make it so that the old versions of those functions look at the struct that they're given, figure out which timezone they're for, and then ignore what's in the struct and use whatever the rules are supposed to be for that particular date. 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. I had actually originally developed std.datetime's Windows stuff using wine, so I had buggy code because of this, which was caught as soon as someone (I forget whether it was me or someone else) actually ran the tests on an actual Windows box.

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. So, any Windows program that tries to look up a time zone with wine will fail, because wine is not using the names that Windows uses even though they're supposedly mimicking the Windows registry. To work around that, when I wrote std.datetime, I was actually looking at each time zone registry entry to look at the name it had for standard time (since it was the same name as the registry key on Windows), so it _was_ compatible with wine. However, as it turns out, the values in the registry entry are locale-dependent (unlike the registry key itself, which is always in Engish). So, the tests failed on systems for folks outside the US (e.g. Kenji, being in Japan, ran into the issue and was actually the one to fix it so that std.datetime used the registry key rather than looking into the entry for the time zone name).

I have not actually tested any of that with wine recently, so it's possible that they've fixed one or both of those issues or that it's fixed if you tell it that you're using a newer version of Windows, but the last time I checked, both of those were still broken on wine. And I really should have created issues in the wine bug tracker for them, but I've just never gotten around to it.

But it's the sort of thing that you probably don't catch unless you're dealign with specific time zone stuff in a way that most programs don't do.

- Jonathan M Davis

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.

On Monday, July 03, 2017 19:57:35 Shachar Shemesh via Digitalmars-d wrote:
> 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.".

LOL. I did not know that, though since IIRC, you're one of the guys who works at Weka, it does not surprise me that you'd be aware of how badly MS has dealt with Israel and time zones.

> > 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] :-).

It probably isn't terribly hard. I've just never gotten around to dealing with it.

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

Yeah, it wouldn't surprise me if wine were doing something where it expected to be able to link the registry keys to the time zone files on disk (I don't know why else they would have done it that way). And as such, it's probably not exactly a quick and easy fix. All of that is probably at least somewhat buggy though given the discrepancies between the time zones that *nix uses and the ones that Windows uses. Fortunately, few programs are going to care about the exact conversions at any specific point in time so long as it's close. But regardless, what they've done with the registry keys makes it impossible to look up a specific time zone without realizing that you're running in wine and doing something differently for wine (which goes against the whole bug-for-bug compatibility thing).

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

Indeed.

- Jonathan M Davis