Re: mktime problems when adjusting tm_isdst
I guess I would benefit from a succinct explanation of what mktime(`TZ=Europe/Paris 1996-01-01 00:00:00 tm_isdst=1') is supposed to mean. Paul's assertion ...
Surely the result should be `1996-12-31 23:00:00 tm_isdst=0'.
..., while perhaps true, doesn't seem patently obvious. If I took `TZ=Europe/Paris 1995-06-01 00:00:00 tm_isdst=1', for example, and added six months, I think I would prefer to see a `1996-01-01 00:00:00 tm_isdst=0' mktime() result. In any case, a clear definition will tell us what to do with the code. Bradley
Date: Tue, 10 Oct 1995 11:57:01 -0400 (EDT) From: Bradley White <bww@fore.com> I would benefit from a succinct explanation of what mktime(`TZ=Europe/Paris 1996-01-01 00:00:00 tm_isdst=1') is supposed to mean. The C Standard is vague about this. mktime is supposed to adjust out-of-range values, but the standard doesn't say how it should adjust things when tm_isdst is out of range. If I took `TZ=Europe/Paris 1995-06-01 00:00:00 tm_isdst=1', for example, and added six months, I think I would prefer to see a `1996-01-01 00:00:00 tm_isdst=0' mktime() result. At least one implementation agrees with you (the GNU C library mktime), but the tz tradition is to assume that when you say ``six months'' you mean ``six months, except that if the DST offset changes during those six months, subtract that change''. In some cases (``2 hours from now'') the tz method is more natural, but in others (``2 days from now'') the ignore-bogus-tm_isdst method is more natural. The ignore-bogus-tm_isdst method deals more consistently with multiple DST offsets and with changes to the base UTC offset, but there is more implementation experience with the tz method. For (too much) more on this controversy, please see the `mktime murk' thread in the comp.std.c newsgroup, e.g. <news:1995Oct5.054100.3591@sq.com>, <news:DFzFA4.Io0@root.co.uk>, <news:45c0ee$3n9@light.twinsun.com>. Leap seconds come into play too, of course!
participants (2)
-
Bradley White -
Paul Eggert