Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!sdd.hp.com!spool2.mu.edu!uunet!mcsun!ukc!pyrltd!root44!gwc
From: gwc@root.co.uk (Geoff Clare)
Newsgroups: comp.std.c
Subject: Re: Questions about mktime()
Message-ID: <2582@root44.co.uk>
Date: 23 Jan 91 13:38:41 GMT
References: <1991Jan18.225155.7310@druid.uucp> <1991Jan20.205039.7056@sq.sq.com>
Organization: UniSoft Ltd., London, England
Lines: 47

In <1991Jan20.205039.7056@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:

>  If the time was actually during the hour that's
>skipped when the clock moves forward, then you were given a "calendar
>time that cannot be represented" and you should return (time_t)-1.

I don't think this is right.  My understanding is that a "calendar
time that cannot be represented" refers to the case where the resulting
return value from mktime() would be outside the range of the time_t type.
The context in which the text appears seems to support this:

    "Returns
    
       "The mktime function returns the specified calendar time
    encoded as a value of type time_t.  If the calendar time cannot
    be represented, the function returns the value (time_t)-1."

The paragraph talks specifically about the return value of type time_t,
so it is clear to me that "cannot be represented" refers to what values
can fit in a time_t.  I think the non-existent times Mark refers to are
meant to be treated the same way as ambiguous times.

>The ambiguous times that are repeated when the clock moves backwards are
>also a problem, but here the Standard is silent and it would seem you're
>free to choose either option if one of these times was specified with
>tm_isdst negative.

I agree that either result is acceptable in this case, but the standard
isn't really silent on this.  It says,

    "A negative value for tm_isdst causes the mktime function to attempt
    to determine whether Daylight Saving Time is in effect for the
    specified time."

The words "attempt to determine", in my view, are there specifically to
cater for the problems at change-over times.  I believe this applies
both to the ambiguous times when changing from dst to std, and to the
non-existent times when changing from std to dst.  In these cases
mktime() is allowed to treat input times with a negative tm_isdst as
either standard or daylight time.  I.e. there are two possible return
values for such times, and both are equally valid.  From the user's
point of view, getting a sensible return value is greatly preferable
to getting (time_t)-1.

-- 
Geoff Clare <gwc@root.co.uk>  (Dumb American mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, London, England.   Tel: +44 71 729 3773   Fax: +44 71 729 3273