date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...) - Mailing list pgsql-hackers

From Tom Lane
Subject date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)
Date
Msg-id 1157.988678318@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: v7.1.1 branched and released on Tuesday ...  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-hackers
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Thomas, what do you think of the persistent reports of date conversion
>> problems at DST boundaries, eg, Ayal Leibowitz's report today in
>> pgsql-bugs?  I cannot reproduce any such problem --- and my local
>> timezone database claims that MET DST transitions are the last week of
>> March, never the first week of April, anyway.  There's something funny
>> going on there.

> Yes. I tried the example on 7.0.2 (and 7.1) and could not get it to
> misbehave. I was guessing that it involves string->date conversion,
> which may pass through timestamp to get there, but it looks like there
> is an explicit text->date conversion function so time zone should just
> never be involved. Really!

I dug through the conversions involved (basically date_in and date_out).
AFAICS the only place where timezone could possibly get involved is that
DecodeDateTime attempts to derive a timezone for the given date/time.
It does this by calling mktime() (line 878 in datetime.c in current
sources).  If mktime() screws up and alters the tm->tm_mday field then
we'd see the reported behavior.  I really don't see any other place that
it could be happening.

A platform-specific bug in mktime would do nicely to explain why we
can't reproduce the problem, too ... OTOH, it's hard to believe such a
bug would have persisted across several RedHat releases, which seems to
be necessary to explain the reports.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Bug in ODBC driver
Next
From: Philip Warner
Date:
Subject: Re: COPY commands could use an enhancement.