BUG in mktime (PR libc/783)

[Andreas Jaeger <jaeger@gnu.org>]

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