This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
BUG in mktime (PR libc/783)
- To: libc-hacker@cygnus.com
- Subject: BUG in mktime (PR libc/783)
- From: Andreas Jaeger <jaeger@gnu.org>
- Date: Fri, 18 Sep 1998 03:49:23 -0400
- CC: Michael Deutschmann <michael@talamasca.wkpowerlink.com>
Hi,
Michael reported a bug in mktime. You can reproduce it with:
$ TZ=America/Vancouver date --date="Apr 5 3:00 1 hour ago"
date: invalid date `Apr 5 3:00 1 hour ago'
The problem is that this is just the change to summertime. For
details see the report below.
I'd appreciate if somebody could look into this problem and came up
with a fix.
Thanks,
Andreas
------- start of forwarded message (RFC 934 encapsulation) -------
To: bugs@gnu.org
Subject: libc/783: mktime() and DST
Date: Thu, 10 Sep 1998 22:49:36 -0700 (PDT)
>Number: 783
>Category: libc
>Synopsis: mktime() does not normalize times in DST changeover
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: libc-gnats
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Sep 11 02:00:00 EDT 1998
>Last-Modified:
>Originator: Michael Deutschmann
>Organization:
>Release: libc-2.0.6
>Environment:
Host type: i486-pc-linux-gnu
System: Linux khar-pern 2.0.36 #5 Mon Sep 7 13:34:44 PDT 1998 i486 unknown
Architecture: i486
Addons: crypt linuxthreads localedata
Build CFLAGS: -O3 -m486 -pipe -fomit-frame-pointer
Build CC: gcc
Build shared: yes
Build profile: no
Build omitfp: no
Stdio: libio
>Description:
(This was done in the America/Vancouver timezone, if it makes any difference)
If mktime() is asked to normalize the time Apr 5th 2:00 1998, it gives an
error.
Although that might seem fair, as Apr 5th 3:00 follows Apr 5th
1:59 due to the start of daylight savings time, it would make more sense
to bounce the time a valid time. This would be consistent with
mktime's behavior for, say "Feb 31st", which is adjusted to Mar 3rd.
I noticed this bug because "date" would give "invalid date" errors when I
used a relative time that happened to point into that zone. When I
reported the bug to the maintainer (Jim Meyering <meyering@ascend.com>),
he could not reproduce it until he moved to a Linux system -- apparently
other C libraries automatically fudge the time (to 1:00).
>How-To-Repeat:
Try `date --date="Apr 5 3:00 1 hour ago"'
(Apr 5 2:00 would more directly cause the problem, but the former example
is more likely to occur in real life.)
>Fix:
>Audit-Trail:
>Unformatted:
------- end -------