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@cam.ac.uk