[LEAPSECS] DNS examples

[Steffen Nurpmeso]

Rob Seaman <seaman at noao.edu> wrote:
 |On Jan 22, 2015, at 3:27 PM, Steffen Nurpmeso <sdaoden at yandex.com> wrote:
 |> One of them is that the count of months start 2014 not 1972, which
 |> extends the representable range of years until 2099.
 |
 |Prior leap seconds don’t vanish - nor do prior Bulletins C. \
 | There certainly may be retroactive use cases that rely on \
 |this mechanism.  It is much cleaner and more robust to support \
 |the entire history of leap seconds.

Ok i'll bite: why this?  This service would only track future
changes with the first adjustment happening at 2015-06-30.

 |> And the other adjustment was that the base drift now is 9-bit, not
 |> 8-bit, still signed though, reaching from -255 to +255.
 |
 |There really is no need for a negative tally.  The mechanism \
 |needs to support the possibility of an occasional negative \
 |leap second, but the geophysics argues against getting three \
 |dozen of these in a row, especially not right off the bat. \
 | The longer the string of positive leap seconds go on, the \
 |harder it will be to force it negative in any physically realistic way.

This is logical.  I indeed have *no* idea on what can happen,
which is one of the reasons that i am on this list, because so
many specialists from many different specialist fields can (or
could) show up.  For example i didn't know that even snow storms
have a measurable effect on earth rotation.
What can happen, yet undiscovered asteroids that fly-by, natural
disasters that radically change the climate, coastline changes
because of massive sand theft for use in concrete and follow-up
motions, coastline changes because of the rise of the mean sea
level, further displacement of mass because of glacier melt,
desert proliferation and atmospherical / clowd changes.  Does
anyone really know what this will mean on the long run.
And, especially, if extending the PHK DNS A record to cover it
makes sense: i.e., what would it mean to life on earth if the
environmental changes would be so that the drift changes cannot be
represented by that record.
So if it is really impossible that the number ever goes negative
then of course the 9-bit could be made unsigned, increasing the
limit to 512.

 |> And here i simply reduced that from 2-bit to a single bit, stating
 |> wether it is a positive leapsecond.  Only if a leapsecond occurs
 |> the DNS record will be updated at all, so it really makes no sense
 |> to store more than a single bit.
 |
 |Bulletin C is issued whether or not a leap second occasion \
 |(currently June and December, but could be any month) corresponds \
 |to an actual leap second.  The encoding (as in PHK’s example) \
 |should be able to represent a positive, negative or absent leap second.

That doesn't make sense to me.  An absent leap second doesn't
change the TAI-UTC drift, so why would you update the record?
Shall an announcment be taken back for whatever reason, the old
record had to be restored.

 |> Well.  PHK follows the IERS format which uses the 1st of the month
 |> after the leap second, i.e., the second after the leap occurred.
 |
 |This is an implementation detail.  PHK’s choice is as good as the other.

And i disagree with that.  The ISO C(99) standard doesn't offer
a JDN-TO-Gregorian and vice versa calculation.  There is the
well-known algorithm from Communications of the ACM, Vol 6, No 8,
but it is not in the standard.  So in order to calculate the
actual date where the drift adjustment occurs you have to face
a very elaborate conversion.  With two more bits for the day the
calculation could be performed when creating the record,
permitting simplemost scripts/programs to display the correct date
and time of the actual leap second by only decoding the DNS
information.

 |> With 2 bits for
 |> a day number (X - 28) the exact date of the leap second could be
 |> collected from the record without any further calculation.
 |
 |According to TF.460 it will always be the last day of the month.

It seems to me that the necessity to change that would only happen
as part of a time-keeping change so massive that the effort this
thread is about would be obsolete.
I still haven't added a IPv6 variant that doesn't suffer from bit
savings.  The syntax of that variant could then also be used for
TXT records and possibly end up as a registrated DNS RR variant.
I'll look into that, tomorrow.

--steffen