This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


> 
>    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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]