I extracted from Ayal the info that he was using timezone
'Asia/Jerusalem'. That zone has the interesting property that
the DST transitions happen *at midnight*, not at a sane hour like 2AM.
I suspect that that is triggering various & sundry bugs in older
versions of mktime().
Ahhh! So "GMT+2" was just an approximation, eh? :/
On a relatively recent Linux (LinuxPPC 2000/Q4) the worst misbehavior
I can find is ...
However on an older Linux (RedHat 5.1) I get: ...
I recommend that all uses of tm->tm_gmtoff from mktime() be guarded
along the lines of
if (tm->tm_isdst >= 0)
believe gmtoff
assume GMT
I'm not sure that tm_isdst == -1 is a legitimate indicator for mktime()
failure on all platforms; it indicates "don't know", but afaik there is
no defined behavior for the rest of the fields in that case. Can we be
assured that for all platforms the other fields are not damaged?
However, this still does not account for the reported failure of date()
since that code path doesn't use the returned value of *tzp --- and
indeed I get the right thing from select date('1993-04-02'), despite
the failure of mktime(). Probably the behavior of mktime() in this
situation varies across different glibc releases. ...
which is just what you'd expect if mktime() fails for this input;
I suppose there's nothing we can do about that except advise people
to update to a less broken libc...
Not sure how much code we should put in to guard for cases we can't even
test (RH 5.1 is pretty old).

- Thomas

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 3 | next ›
Discussion Overview
grouppgsql-bugs @
postedMay 2, '01 at 3:01a
activeMay 10, '01 at 1:55p

2 users in discussion

Tom Lane: 2 posts Thomas Lockhart: 1 post



site design / logo © 2021 Grokbase