time.h critique

[Dave Flater]

Markus,

Thank you for your response, which I comment on below.

> For binary compatibility reasons, we cannot change the size of struct
> tm. We would have to add a new struct tmx, and double all related
> functions, which would give the API a quite clumsy appearance. My plan
> was therefore not to "mess around" with struct tm in any way that might
> break existing applications. I do not think we gain too much by fixing
> struct tm: It is hard to imagine that in any time zone a time will
> repeat itself more than once. Therefore I think it is a reasonable
> convention that xtime_make interprets tm_isdst as positive for the first
> interval, zero for the second interval, negative as a reason for
> signalling an error IF the specified time is ambiguous. If the specified
> time was not ambiguous in the first place, tm_isdst should be ignored.

That will suffice as long as this conventional behavior is mandated in
the spec, very clearly, for xtime_make.  Last time I checked,
subclause 4.12.2.3 of the Rationale of the C standard (1989) let
mktime do pretty much anything when confronted by ambiguous input,
which made it impossible for an application to sort out the
discontinuities in any reasonable, portable manner.

Given reliable behavior as you described above, my desired function
that returns 0 to 2 translations for a struct tm can be implemented in
a few lines of code, with a few calls to xtime_make.

> Surely there are more elegant ways to resolve these ambiguities, but
> instead of trying to improve struct tm, I think it is much better to
> make struct tm mostly irrelevant by giving strfxtime direct access to
> all the available information in the struct xtime and timezone_t objects
> directly.

Granted for strfxtime, but struct tm is needed for xtime_make which
will never be irrelevant.

> >    * Add an explicit interval type, an extended difftime function that
> >      takes two xtimes and returns an interval, and the other obvious
> >      operations.  I defined a bunch of operations over timestamps and
> >      intervals in C++ for XTide 2.0 but for C you probably want to
> >      keep it simple.
> 
> These are indeed rather simple to add, but what would be their semantics
> in the presence of leap seconds?

Now that I read the leap seconds stuff more carefully, I guess you
need to pass the clock_type as well to disambiguate that.

> Yes, but this is a single-line function that everyone who needs it can
> easily add himself.

Granted, the remainder of my suggestions were out of scope for your
current efforts on the C language pe se.

> A requirement for an Olson-like appraoch to implement timezone_t would
> be more appropriate for a standard like POSIX than for a programming
> language standard with a much wider scope.

If there are any POSIX folks listening, I urge them to pursue it.

Regards,
DWF