[tz] isdst bug Europe/Dublin (tzdb-2019c)

Steve Summit scs at eskimo.com
Sun Dec 15 00:56:42 UTC 2019

Robert Elz wrote:
> It makes no sense (to me) at all to convert TAI into any kind of
> (currently used) calendar type measurements -

Fair enough.

> Certainly I don't think it makes any rational sense to have different
> length "years" (regular years and leap years, with a bizarre rule about
> which years are which) in TAI - though it is certainly sensible to have
> a unit bigger than seconds in which to measure lengthy periods...

Vernor Vinge has a wonderful set of SF novels ("A Deepness in the
Sky", etc.), set in the far future, in which they measure time in
kiloseconds, megaseconds, etc.  There's also this marvelous
passage concerning legacy software:

	Via a million million circuitous threads of inheritance,
	many of the oldest programs still ran in the bowels of
	the Qeng Ho system.  Take the Traders' method of timekeeping.
	The frame corrections were incredibly complex -- and down
	at the very bottom of it was a little program that ran a
	counter.  Second by second, the Qeng Ho counted time from
	the instant that a human had first set foot on Old Earth's
	moon.  But if you looked at it still more closely...
	the starting instant was actually about fifteen million
	seconds later, the 0-second of one of Humankind's first
	computer operating systems.

> What we really need to do is recognise that there is not [...] just one
> definition (one unit) "a second" - there are two entirely different
> things we use commonly [...] One is the thing TAI uses [...] The other
> is 1/84600 of a day [...] where a day is defined according to the
> (varying) rotations of the earth, and hence the second is not a fixed
> length, but a variable one.  That's the POSIX second (time_t) value [...]

I don't entirely disagree, and indeed bringing UT1 to bear is an
attractive way of trying to rescue the benighted Posix definition,
but time_t is certainly not defined that way now, and I'm not aware
of anyone implementing it that way!  time_t seconds really are
UTC/TAI seconds (except, of course, when they're not).

[But perhaps what you're saying is that redefining time_t as UT1
is part of "What we really need to do".]

More information about the tz mailing list