> >> 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?
Yup, that would be the best. Either that or CET/CEST.
I'm using the timezone that in the GUI is called "(GMT +01:00)
Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna". srtftime with %z
calls it "W. Europe Daylight Time".
> 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.)
Actually, I was sure that was wrong, but started looking it up, and it
seems it's about right. See
http://www.sp.se/metrology/timefreq/eng/standard_time.htm for an
official take on the summertime rules. I *think* that is the EU rules.
> 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.
That could definitly be. Since before 1970 they say there is no DST at
all (remember the old issues), it wouldn't surprise me a bit if they
took this kind of shortcut.
> 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?
Well, Windows specific we could do a translate table. SInce there is a
finite (and not *huge*) number of timezones. But we'd have to figure out
for each one which to match. But that won't work for unix I think - the
lookup table would be just huge considwering all possible
combinatinos...
//Magnus
