Date: Fri, 02 Oct 1998 11:24:54 +0100 From: Markus Kuhn <Markus.Kuhn@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.