"Magnus Hagander" <mha@sollentuna.net> writes:
>> It occurs to me that with a check this thorough, we might be
>> able to finesse the problem on Windows with the system
>> returning very nonstandard timezone abbreviations.
> It does *not* pick up my timezone.
Drat. I assume from your domain name that Europe/Stockholm would
actually be the best choice for you? What Windows timezone setting
are you using for this test?
The following possibilities are rejected per:
> DEBUG: Reject TZ "Europe/Stockholm": at 16844400 1970-07-15 00:00:00
> std versus 1970-07-15 01:00:00 dst
If you look in src/timezone/data/europe you will see that the zic
database thinks Sweden was on strict GMT+1 (no daylight savings) between
1916 and 1980, and since 1980 they were on EU daylight-savings rules.
Does that square with your ideas of reality? (If it does not then we
should just punt the problem upstream to the zic people, but I will
assume here that their research is good.)
What I suspect given the above is that Windows has no clue about
historical reality and is retroactively applying the current DST rules
back to 1970, thus deciding that 1970-07-15 was on DST when it was
really not.
I have seen related problems on my own machine. HPUX 10.20 seems to not
have its facts entirely straight concerning US daylight-savings laws
that were in effect in the 1970s; our current code fails to match
against the system behavior because of this.
I thought about restricting the scope of the TZ testing to start in 1990
or so to avoid this, but that seems certain to fall foul of the other
problem, which is distinguishing closely-related timezones (cf Chris
K-L discovering that he lives in Antarctica, a few days back...)
Maybe the whole match-on-behavior approach is wrong and we need to do
something else, but I'm really unsure what. Ideas?
regards, tom lane