C Code for draft-newman-datetime-00.txt
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
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