> 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.
Yes. It is possible to call DecodeDateTime() so that it *never* tries to
derive a time zone (call with the last argument set to NULL), but that
also causes it to reject date/time strings which have an explicit time
zone. We certainly would want to accept something like
select date('1993-04-02 04:05:06 PST');
(even though for a date-only result it is overspecified), so calling
with NULL is not the right thing to do (I tried it, then realized the
bad effect).
> 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.
It is also hard to see how such a bug would not be similarly manifested
in Mandrake, Debian, etc etc.
For this particular problem, I'd like to see the "DateStyle" setting,
the time zone setting, an example of the problem (does not require a
table, but just a date string conversion), and the output of "zdump -v"
for the timezone in question.
I'm not sure how to handle date/time bug reports which are not
reproducible on our machines. Certainly date/time issues are the most
problematic in terms of number of bug reports, but they are also
probably the most sensitive to machine configuration and user's
location, so all in all I think the types are doing very well. I don't
want to sound complacent, but it is probably sufficient to fix
reproducible problems to keep our date/time data types viable, and we
are doing far more than that over time :)
- Thomas
