Обсуждение: Re: [pgsql-hackers-win32] Weird new time zone

>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.  That is,
>we might simply "#ifndef WIN32" the matching of zone names in
>try_timezone(). However I do not know whether this would yield
>reasonable results for all the zones supported by Windows.
>Does anyone want to try it?

I tried this, basically changing to:
#ifndef WIN32
            if (strcmp(TZABBREV(cbuf), pgtm->tm_zone) != 0)
            {
                elog(DEBUG4, "Reject TZ \"%s\": at %ld
\"%s\" versus \"%s\"",
                     tzname, (long) pgtt,
                     pgtm->tm_zone, cbuf);
                return false;
            }
#endif

This is what you meant, rihgt?

It does *not* pick up my timezone. 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
DEBUG:  Reject TZ "CET": at 16844400 1970-07-15 00:00:00 std versus
1970-07-15 01:00:00 dst
DEBUG:  Reject TZ "MET": at 16844400 1970-07-15 00:00:00 std versus
1970-07-15 01:00:00 dst
DEBUG:  Reject TZ "Etc/GMT-1": at 16844400 1970-07-15 00:00:00 std
versus 1970-07-15 01:00:00 dst


It didn't pick it up before either, but it didn't get better.

Would probably be good if someone where it actally picks up the correct
timezone could test this as well. Or if someone knows a TZ that matches
and I can change my syste mtemporarily. Just don't want to have to test
through each and every timezone..


//Magnus

"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

Tom Lane wrote:
> 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?

I threw out the matching idea to Magnus as a crazy idea, and I am
surprised we ended up actually using it, but I can't think of a less
crazy idea either.

If we can't find a timezone match should we start looking only from
+1990?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

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

How about scanning backwards until you have <= 1 choice or decide to
give up?

-O

Oliver Jowett <oliver@opencloud.com> writes:
> How about scanning backwards until you have <= 1 choice or decide to
> give up?

Hmm ... that really seems like not a bad idea.  Scan all the available
timezones, score each on how far back it goes before a mismatch, take
the one that goes furthest back.  I'm not sure what to do about ties,
nor what the minimum "passing score" ought to be, but seems like the
germ of an answer.  Comments anyone?

            regards, tom lane