C Code for draft-newman-datetime-00.txt

Antoine Leca Antoine.Leca at renault.fr
Fri Jan 17 10:02:10 UTC 1997

Hi Ken, Hi Tom, 

Tom Peterson wrote:
> > Since ISO C doesn't appear to present restrictions here and TOG says they
> > don't support negative time_t's, perhaps this is an area where an industry
> > precedent should be set.  I've yet to see an errno defined for mktime() on
> > other systems, but I don't see anything precluding it.  Is this something we
> > should consider adding to the tz code base? 
and Ken Pizzini answered:
> The question I have to ask here is: are we working on an ANSI/ISO C
> standard compatible interface, or a POSIX/TOG based standard?  If
> the latter we can work with the understanding that time_t values
> represent seconds since some epoch

It's my understanding that the current TZ code request it.

> and consider following TOG's
> lead in saying that negative time_t values are not allowed. 

OTOH, I don't fell this is requested by the current code base.

> But if we are working on something that trancends POSIX compliance
> and should work on any standard C system then I don't feel that
> we can reasonably rule out negative time_t values -- the C
> standard allows far too many possible underlying semanatics
> for time_t values.

However, we can't aim at full C portability, since the code base made
in *many* places the assumption that time_t is an integral type,
counting seconds.  And the C standard clearly states other
implementations are possible.

So, as you and Tom point out, we are "between two chairs".

> > Is there an existing errno value/macro that
> > would fit the description of "time is not representable"?
> The best existing one I see is ERANGE, but the explanitory text
> on this system says "Result too large", so it isn't perfect.
> (I feel that the description has a bug myself -- a range error
> really does encompass more than just "too large" a result.)

As the current standard says, this seems correct.  ERANGE is used
for signaling overflowing of mathematical operations.  And the
standard explicitly says that it *could* be used for signaling
underflows, but doesn't enforce this behavior.  If your system
don't do it, "Result too large" seems a good description to me.

I don't like the idea of re-using ERANGE, because mktime() can fail
for others reasons than excessing the available values for time_t
(one obvious example is a time in the autumn overloapping period
with tm->tm_isdst==-1).
I think a new constant is in order (I don't like the idea of a new
signaling mechanism); what about EILTIME?

Furthermore, since mktime can fail for different reasons (before
Epoch, result too large, wrong DST setting, autumn indetermination,
spring gap; others?), perhaps can we set up different constants?

I also want to bring this discussion to <news:comp.std.c> as well, in
part for bringing this to the attention of the members of the comittee
in charge of C standardization, in part for asking the C gurus about
the choice of an ESOMETHING constant(s).



More information about the tz mailing list