comments on draft ISO C9x changes to <time.h>

[Joseph S. Myers]

On Mon, 15 Jun 1998, Antoine Leca wrote:

> OTOH, in the realm of POSIX, there is a quite natural
> extension to this mechanism which fits the need:
> 
> struct tzinfo *tzalloc (
>   const char *tzspec);             /* if NULL, use local time */
> 
> where tzspec has the same format as the contents of the
> POSIX.1 TZ environment variable (with the usual extensions,
> such as Olson's : prefix, allowed).
> 
> This function yields a null pointer if given an invalid
> specification; the storage allocated by this function can
> be freed with `free'. 

It might make sense to use the same sort of interface as for the POSIX.2
regular expression functions, e.g.

int tzcomp(timezone_t *zone, const char *tzspec);
size_t tzerror(int errcode, const timezone_t *zone, char *errbuf,
               size_t *errbuf_size);
void tzfree(timezone_t *zone);

tzcomp would return zero on success, or an error code otherwise
(e.g. TZ_BADSPEC for an invalid tzspec string, TZ_NOMEM for allocation
failure or implementation defined values for other errors, e.g. in a
timezone file); tzspec would be a POSIX.1 TZ value or NULL for an
implementation defined local timezone.  This allows extension through the
use of the implementation defined values beginning with ':'.  tzerror
would convert an error code to a string (modeled on regerror); tzfree
would free any allocated parts of the timezone_t structure.  The structure
could have some specified elements (e.g. UTC offset) if these are useful
and can be sensibly defined (i.e., a timezone_t can represent a complete
timezone history covering the past and future - what date's offset should
be given?).

> For the leapseconds, there is first a very delicate inter-
> operability problem, since POSIX.1 request time_t value to
> *not* record any leap second information at all.
> So I have no practical solution here, outside the one
> proposed in CD1, i.e. to extend struct tm to have a new
> field storing this information.

The most compatible solution would be to use Markus Kuhn's CLOCK_UTC with
nanosecond values up to 1999999999 during leap seconds (and if the system
clock ticks TAI the library handles the conversion using a leap second
table).  This would however require new interfaces for time conversion
that take times with nanoseconds.

What is the `correct' time display to give for a leapsecond in a zone with
an offset from UTC that is not an integral number of minutes?  Have there
actually been any such zones since the start of the leapsecond system?

-- 
Joseph S. Myers
jsm28 at cam.ac.uk