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

Joseph S. Myers jsm28 at
Mon Jun 15 09:29:58 UTC 1998

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

More information about the tz mailing list