mktime problems when adjusting tm_isdst

[Paul Eggert]

   Date: Tue, 10 Oct 1995 11:57:01 -0400 (EDT)
   From: Bradley White <bww at 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 at sq.com>, <news:DFzFA4.Io0 at root.co.uk>,
<news:45c0ee$3n9 at light.twinsun.com>.  Leap seconds come into play too,
of course!