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

[Michael H Deckers]

    On 2019-12-15 00:04, Robert Elz wrote:

> It makes no sense (to me) at all to convert TAI into any kind of
> (currently used) calendar type measurements - the calendars we use
> are designed to match astronomical reality (the various rotations of
> the earth) and those things just don't take constant periods, even
> though they're close.   But that's what we have decided we want from
> our calendar system - we want it to alwqays be summer in January, and
> winter in July (those unfortunate enough to be in the wrong hemisphere
> can adapt as needed), and TAI (alone, withough some kinds of
> corrections) simply does not provide that.   If you want some kind of
> calendar for TAI you'd be better to convert it to stardates or something.


     The notation of values of TAI using the Gregorian calendar is helpful
     when comparing time scales. For instance, in the recent BIPM definition
     of TAI, as sanctioned by the 26th CGPM 2018, online at
     [https://www.bipm.org/en/CGPM/db/26/2/], we read:

         "TT - TAI = 32.184 s exactly at 1 January 1977, 0h TAI
          at the geocentre, in order to ensure continuity
          of TT with Ephemeris Time"


> ....
> What we really need to do is recognise that there is not (rather should
> not be) just one definition (one unit) "a second" - there are two entirely
> different things we use commonly, which just happen to be so close together
> that we have tried to force them to be the same thing.
>
> One is the thing TAI uses (and UTC with leap second corrections) - which is
> a period defined by something that we believe to be fixed - always the exact
> same duration, and so can be used for comparing durations from measurements
> collected separately,
>
> The other is 1/84600 of a day (a bizarre choice, but never mind) 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, but is also how humans have measured time ever since
> we started doing it - initially it wasn't understood that the length of a
> day wasn't constant (as it so nearly is) but 60 seconds a minute, 60
> minutes an hour, 24 hours a day, (ie: 86400 seconds a day) is what has been
> used for a long time now, (with the more precise measurements appearing as
> we gained the ability to measure them, sundials to be able to measure house,
> hourglasses to meaure minutes, and fractions thereof somtimes, ...)
>
> We really should be using two different names for these two different things,
> rather than trying to pretend that a "second" can be defined which suits
> both purposes.


     I disagree.

     You are right that the time scales UT1 and TAI have different 
rates; and
     there are several other time scales used in astronomy (eg TCB, TCG, 
TDB)
     with still other rates. This is caused by physics (not just by the
     tradition of mean solar time derived from Earth rotation).

     Astronomers want to be able to compare these time scales and convert
     between them, hence they _must_ express their values in common units.
     Even the mere expression that the time scales differ in rate requires
     the use of common units.

     For instance, the differential quotient d(TAI - UT1)/d(UT1) is a
     measure of the speed of rotation of the Earth called "excess length
     of day" (it actually was negative, -20 µs/d on 2019-12-11).
     We cannot compute TAI - UT1 unless the values of TAI and UT1 are
     expressed in the same units. Still another non-SI time unit would
     only confuse the issue.

     Beyond that, the quantity "mean solar second" = d(TAI)/d(UT1)·(1 s)
     would be a bad choice for a unit since d(TAI)/d(UT1) changes
     unpredictably over time.

     In the presence of different time scales, it certainly is necessary
     to designate the time scale in which a specific datetime was
     observed; in ISO 8601 notation, the suffix Z indicates a UTC value,
     a suffixed offset indicates a local civil time scale derived from
     UTC; and otherwise, an appended time scale acronym (as above) is
     often used to indicate the time scale.

     Michael Deckers.