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