[tz] isdst bug Europe/Dublin (tzdb-2019c)
john.haxby at oracle.com
Sun Dec 15 13:03:44 UTC 2019
> On 15 Dec 2019, at 05:16, Robert Elz <kre at munnari.OZ.AU> wrote:
> Date: Sat, 14 Dec 2019 19:56:42 -0500
> From: scs at eskimo.com (Steve Summit)
> Message-ID: <2019Dec14.1956.scs.0008 at 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.
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.
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.
 a certain database is, finally, using that to measure elapsed time.
More information about the tz