Re: BUG in mktime (PR libc/783)

[Ulrich Drepper <drepper@cygnus.com>]

Andreas Jaeger <jaeger@gnu.org> writes:

> 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 mktime returns on other systems (e.g, Solaris) for
the illegal broken down date

	Apr 5 2:00

a non-error value.  A simple program printing the values for 1:00,
2:00 and 3:00 executed on Solaris 2.7 results in

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t1 = 891766800, t2 = 891766800, t3 = 891774000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

With glibc it results in

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t1 = 891766800, t2 = -1, t3 = 891770400
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think the glibc interpretation is at least equally well.  The mktime
specification says it returns -1 if the date cannot be represented.
This is the case for the illegal date 2:00.


To get GNU date running I think it should be possible to do something
like this:

	t = mktime (tp);
	if (t == -1)
	  {
	    substract one hour from `tp'
	    t1 = mktime (tp);
	    add two hours to `tp'
	    t2 = mktime (tp);
	    if (t1 != -1 && t2 != -1 && t2 - t1 == 3600)
	      {
	        ...handle DST switch correctly...
	      }
	  }

In this case the program can decide whether it is 1:59, 3:00, or 1:59,
2:00, 3:01.  Maybe the case where yyRelHour etc is != 0 needs some
special handling but this is the only really portable way.  Relying on
mktime to return a useful value for an illegal data is not correct.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------