Thread: Re: localtime() for win32 problem.

Hmm. Looks like we are trying to "score" timezones using date/times pre
midnight, Jan 1 1970, which is a no-no for win32 (IIRC, this was a prime
motivator for rolling in a pg_timezone library).

Have to avoid this, or change pgtz.c following lines 184 and 304 to
correctly deal with a NULL return from the native localtime.

Cheers,
Claudio




> -----Original Message-----
> From: Korea PostgreSQL Users' Group [mailto:pgsql-kr@postgresql.or.kr]
> Sent: Thursday, 29 July 2004 2:06 PM
> To: pgsql-hackers-win32@postgresql.org
> Subject: [pgsql-hackers-win32] localtime() for win32 problem.
>
>
> I found that localtime do not work same between linux and win32.
>
> timet = -1000000; /* minus value */
> localtime(&timet);
>
> above codes do not work win32. (in Microsoft C, mingw gcc too)
>
> so, score_timezone() function in src/timezone/pgtz.c should
> be changed.
> this problem is continuous with initdb when initdb run
> without setting TZ env value.
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Claudio Natoli <claudio.natoli@memetrics.com> writes:
> ... change pgtz.c following lines 184 and 304 to
> correctly deal with a NULL return from the native localtime.

Ah, that would seem to be the problem.  Also, has anyone rechecked with
this version of pgtz to see if we can dispense with testing time zone
name equality and still pick the right zone on Windows?

            regards, tom lane

>> ... change pgtz.c following lines 184 and 304 to
>> correctly deal with a NULL return from the native localtime.
>
>Ah, that would seem to be the problem.  Also, has anyone rechecked with
>this version of pgtz to see if we can dispense with testing time zone
>name equality and still pick the right zone on Windows?

Well, it puts me in "Africa/Ceuta" instead of "Europe/Stockholm"... It
picked a couple of TZs correctly in the US, but when I set it to -7
Arizona, the entire postmaster fails to start with "FATAL: postmaster:
could not locate matching postgres executable". (Other -7 timezones do
work.  -7 Arizona works with the check being in there). I had it die on
one other timezone I tested in the US, I thin kit was Atlantic time.


I tested by #ifdefing out the following code from pgtz.c:

        if (systm->tm_isdst >= 0)
        {
            /* Check match of zone names, too */
            if (pgtm->tm_zone == NULL)
                return -1;        /* probably
shouldn't happen */
            memset(cbuf, 0, sizeof(cbuf));
            strftime(cbuf, sizeof(cbuf) - 1, "%Z", systm);
/* zone abbr */
            if (strcmp(TZABBREV(cbuf), pgtm->tm_zone) != 0)
            {
                elog(DEBUG4, "TZ \"%s\" scores %d: at
%ld \"%s\" versus \"%s\"",
                     tzname, i, (long) pgtt,
                     pgtm->tm_zone, cbuf);
                return i;
            }
        }


That's what you wanted tested, right?

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:
>> Ah, that would seem to be the problem.  Also, has anyone rechecked with
>> this version of pgtz to see if we can dispense with testing time zone
>> name equality and still pick the right zone on Windows?

> Well, it puts me in "Africa/Ceuta" instead of "Europe/Stockholm"...

Something wrong there, as a quick look at the rule files shows that
those zones have different daylight-savings rules before 1986.  What
does DEBUG4 output show about the scores for those zones?  Perhaps
Windows has wrong historical data even later than that?

            regards, tom lane