First proposal for new ISO C 9x time API

Paul Eggert eggert at twinsun.com
Sat Sep 5 21:16:54 UTC 1998


   Date: Sat, 05 Sep 1998 21:40:27 +0100
   From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>

   I prefer sound and consistent semantics here, and I think they are only
   possible with minute UTC offsets.

The implementation that I'm typing this message on (Solaris 2.6) has
time zones that are not at integral offsets from UTC (e.g. Liberia
until 1972).  This implementation does not have any semantic problems
with leap seconds that are not the last second in a localtime minute,
since it does not support leap seconds.

I don't think that the C standard should disallow this type of
implementation, which is fairly common in practice.

   If you think that civil time zones defined relative to UT1 will
   become fashionable one day, then why on the other side should we
   allow only second resolution and not add nanoseconds in addition?

Historical practice was to specify UTC offsets only to the nearest
second.  For example, I believe that the legal definition of Paris
Mean Time (used as the basis for official time in France until 1978)
was 9 minutes and 21 seconds ahead of Greenwich Mean Time.

I've never seen any records of more-precise UTC offset specifications;
I don't think the standard needs to support this.

   I feel the KISS principle dictates minute offsets here.

Isn't it simpler to follow widespread existing practice (POSIX.1,
Linux, Solaris, SVR4, BSD, etc., etc.), which uses second offsets?

   I have been thinking about this, and the only reasonable solution I can
   think of is that we always assume that we do not fall into a leap
   second.

I don't see why this is the only reasonable solution; it's akin to
assuming that we do not fall into the 31st day of a month, since not
all months have 31 days.

GNU mktime does not make this assumption; if you add 1 to 23:59:59,
you'll get 23:59:60 if that leap second happens to exist and if the
host support leap seconds.  So there's an existence proof that leap
seconds can be handled properly.

I don't think the C standard needs to _require_ proper handling of
leap seconds; but the standard should not _disallow_ it.

   > It would be a good idea to use a common prefix for the structure elemen=
   ts
   > (xtm_nsec, xtm_sec, etc.).

   I never understood what these common prefixes are good for.

I believe that they were put in for historical reasons.  In very old
versions of the C compiler, all structure members lived in the same
name space.  Nowadays this original motivation is not important, but
the tradition lives on in some places.  Personally, I don't think the
xtm_ is needed, but I don't care too much one way or the other.



More information about the tz mailing list