Proposal for new ISO C 9x time API

[Paul Eggert]

   Date: Fri, 02 Oct 1998 11:24:54 +0100
   From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>

   It is hard to imagine that mass market silicon microprocessors will
   leave UHF and break through the 10 GHz barrier for internal clock speed
   during my lifetime.

Perhaps, but that doesn't mean that C apps won't run into sub-ns
clocks soon.  EE Times online reports that already people are doing 5
GHz in the labs with InP SRAM, with first commercialization rumored in
the 2001 timeframe (ok, ok, the schedule may be marketing hype, but
the underlying technology seems to be the real deal).  NTT has a demo
350 GHz InP HEMT transistor that is an amusing feasibility study.

I expect to see processors exceeding 1 THz in my lifetime (and I hope
you live so long too :-).

   Reading out an internal monotonic clock counter, converting it to a
   portable UTC representation, and returning it via a system call
   interface

One advantage of using a simple integer representation (instead of a
struct) is performance: an implementer can avoid the conversion and
system call overhead entirely, and compile the request for a timestamp
into a direct access of the clock register.

   I expect tz_error usually to be called immediately after a tz_prep has
   signalled a problem. If programmers are sharing a bad timezone_t
   across thread, then honestly, that is their problem.

Returning an integer value suitable as input to strerror would fix
this problem in a thread-safe fashion, without having to use malloc.

   Related problem: What is the semantics of decimal fractions of minutes
   and hours during a leap second. These are obviously illdefined and a
   neat solution is not possible

Why not?  The day is just 1 second longer, so you use a denominator of
86401 instead of 86400 when computing the fraction.  Of course you
should use the larger denominator throughout the day, not just during
the leap second.