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). Amicalement, Antoine