date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)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