mktime problems when adjusting tm_isdst

Paul Eggert eggert at
Tue Oct 10 17:22:55 UTC 1995

   Date: Tue, 10 Oct 1995 11:57:01 -0400 (EDT)
   From: Bradley White <bww at>

   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

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>, <news:DFzFA4.Io0 at>,
<news:45c0ee$3n9 at>.  Leap seconds come into play too,
of course!

More information about the tz mailing list