On 15 Dec 2019, at 05:16, Robert Elz <kre@munnari.OZ.AU> wrote:
Date: Sat, 14 Dec 2019 19:56:42 -0500 From: scs@eskimo.com (Steve Summit) Message-ID: <2019Dec14.1956.scs.0008@quinine2.home>
| [But perhaps what you're saying is that redefining time_t as UT1 | is part of "What we really need to do".]
First, part ofmy belief is that nothing that POSIX (or the C std) has related to time is even close to adequate.
For time_t what I mean is that it should not survive as it is, we need (just for "seconds" time counters) two entirely different things, which keep track of the different ways we count time, differently. Currently this is fudged with how one obtains the time_t (CLOCK_MONOTONIC, CLOCK_REALTIME etc) but because they all produce the same type (time_t) they can all be processed the same way - so a CLOCK_MONOTONIC result can be handed to localtime() which makes no rational sense at all.
kre
I completely agree. IIRC, Posix defines the time returned by various things as "since approximately 1970-01-01 00:00:00 UTC" or "since an undefined epoch". Basically, the first time_t roughly gives the current wall-clock time in the Greenwich observatory in northern hemisphere winter (you can offset it to whatever timezone you think you are in). The second time_t gives you a reliable way of measuring elapsed time[1]. The central assumption of posix time-of-day is that a day is exactly 86400 seconds which is handy if you're doing quick and dirty coding: but how long does sleep(86400) sleep for over a leap second? (There are good, bad and ugly possible answers. And accurate ones.). I think Go has the right idea. A time.Time object works for both elapsed and wall-clock time by holding two possible values. So when there's been a leap second, noon-to-noon should show an elapsed time of 86401 seconds (I wonder if it does?) and if you want to sleep() from noon to noon you need to sleep the calculated interval, not 86400. It's a mess. jch [1] a certain database is, finally, using that to measure elapsed time.