Re: A patch for mktime.c and tz*.c.

[Paul Eggert <eggert@twinsun.com>]

   From: hjl@lucon.org (H.J. Lu)
   Date: Fri, 6 Nov 1998 16:43:43 -0800 (PST)

   The key here is "daylight" stores the DST offset which is used to
   compute DST at the given time.

But the problem is that there is no single DST offset.  Different DST
offsets are used at different times.

   As long as "daylight" is correct, I don't see how it can be a problem.

But __daylight is the problem.  It can't possibly be ``correct'' (in
the sense that you describe) in general, since __daylight is a single
value, and it can't possibly represent the multiple values that are in
use in practice.

You seem to be under the impression that glibc 2.0.100 __daylight
means ``the ruleset in use at time T has DST''.  This is incorrect.
__daylight is a global flag, which means that at some point in time
(either in the past, present or future), DST was, is, or will be in
effect.  You can't reliably use this variable to store the DST offset
unless the same DST offset is used consistently throughout time.

   > This is an instance of a more general problem.  Given the current
   > mktime interface, mktime _must_ guess in some cases.  For example, how
   > much should mktime adjust 1989-01-01 00:00:00 with tm_isdst=1 in
   > Newfoundland, which used a 2-hour DST offset in summer 1988 and a
   > 1-hour DST offset in summer 1989?  There's no way for mktime to know
   > whether a 2-hour or a 1-hour adjustment is correct.

   Since it is not speficied, there is no unique answer.

But if you follow your line of reasoning to its logical conclusion,
then it's OK for mktime (with tm_isdst==1) to assume a 2-hour DST
offset for today's date in London, since London used 2-hour DST in
1947.  After all, there's no way for mktime to tell whether the
original time came from 1947 or from this summer, so mktime should be
allowed to assume either 1- or 2-hour DST offset for today's date.

The basic problem is that mktime cannot do a perfect job, since its
interface is inadequate.  Since it can't do a perfect job, it might as
well stick to the heuristic used in glibc 2.0.100, since this works
well enough in practice.  The method that you propose has problems in
time zone rulesets like London that have multiple DST offsets.