> 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
> else
> 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