> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
