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: hjl@lucon.org
- Subject: Re: A patch for mktime.c and tz*.c.
- From: Paul Eggert <eggert@twinsun.com>
- Date: Fri, 6 Nov 1998 22:43:45 -0800 (PST)
- CC: drepper@cygnus.com, libc-hacker@cygnus.com
- References: <m0zbz2u-0000V3C@sea.lucon.org>
From: hjl@lucon.org (H.J. Lu)
Date: Fri, 6 Nov 1998 19:28:15 -0800 (PST)
Cc: drepper@cygnus.com, libc-hacker@cygnus.com
> The patch that you sent does not behave the way that you describe.
> E.g. the patch has __tzfile_read set __daylight. But this action
> occurs rarely, only at the start of the program, and after TZ changes;
> it doesn't occur for each ``given time''. So (in general) it will
> disagree with the difference between standard time and DST at ``the
> given time''.
That is absolutely false.
Why? mktime does not read a zoneinfo file every time it is called.
(mktime may be slow, but it's not _that_ slow. :-)
time_t
mktime (tp)
struct tm *tp;
{
#ifdef _LIBC
/* POSIX.1 8.1.1 requires that whenever mktime() is called, the
time zone names contained in the external variable `tzname' shall
be set as if the tzset() function had been called. */
__tzset ();
#endif
Yes, mktime invokes __tzset; but POSIX.1 does not require __tzset to
set __daylight, and indeed it usually doesn't. Furthermore, even when
__tzset does set __daylight, it does so globally, and without
reference to a particular time, so your idea that __daylight refers to
a particular time doesn't match what actually occurs.
I'm not sure it's worth your and our time to pursue this further, as
the bug does not seem to occur in 2.0.100. But if you want to go
ahead, please read the code carefully; it doesn't hurt to trace
through a couple of executions. It's not as straightforward as it
first appears. (No doubt it could be made clearer.)