Re: Bug #630: date/time storage problem: timestamp parsed

> Looks like it's a "bug" in mktime() on FreeBSD: it doesn't seem to do
> so well with invalid times that happen between daylight savings
> time... or is that a postgres thing for not kicking up an error (out
> of bounds time)? Or should 2am PST be converted to 3am? -sc

Here is the man page on Linux:

The mktime() function converts a broken-down time structure, expressed
as local time, to calendar time representation. The function ignores the
specified contents of the structure members tm_wday and tm_yday and
recomputes them from the other information in the broken-down time
structure. If structure members are outside their legal interval, they
will be normalized (so that, e.g., 40 October is changed into 9
November). Calling mktime() also sets the external variable tzname with
information about the current time zone. If the specified broken-down
time cannot be represented as calendar time (seconds since the epoch),
mktime() returns a value of (time_t)(-1) and does not alter the tm_wday
and tm_yday members of the broken-down time structure.

Does that look similar to FreeBSD?

I don't think that our code checks explicitly for a "-1" return, since
the range is checked just before the call, but it would probably be a
good idea if it did (assuming that other mktime() implementations had
the same convention for an error return of course).

This is the first report I can remember in 6 years of this particular
symptom, and I have the strong feeling that no matter what we end up
doing there *is* a problem with the FreeBSD database of time zones or
(possibly) in its implementation of mktime().

What do you see as the return value from mktime()?

- Thomas