This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: A patch for mktime.c and tz*.c.
- To: eggert@twinsun.com (Paul Eggert)
- Subject: Re: A patch for mktime.c and tz*.c.
- From: hjl@lucon.org (H.J. Lu)
- Date: Fri, 6 Nov 1998 18:20:23 -0800 (PST)
- Cc: drepper@cygnus.com, libc-hacker@cygnus.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.
How come __daylight can have multiply values at a given
time in mktime? Please show me a testcase.
>
> 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.
So __daylight indicates if DST was, is, or will be in effect
at the given 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.
When there is a difference, where does it come from?
I believe it comes from SDT and DST. Does glibc 2 know
the offset between SDT and DST at the given time? If
the answer is no, there is a bug in glibc 2. If the
answer is yes, which I believe is the case, I store
the offset in __daylight and use it in mktime. What is
wrong with that?
>
> 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.
>
I guess it should be easy for you to come up with a simple
tescase.
FWIW, I discovered those mktime bugs with VSX-PCT. It failed
with GMT0BST. At lease, my change passes VSX-PCT.
--
H.J. Lu (hjl@gnu.org)