[LEAPSECS] Coming of age in the solar system

[Paul Sheer]

On Sat, 2010-09-04 at 22:43 +0000, Poul-Henning Kamp wrote:

> In message <1283634327.9574.120.camel at localhost>, Paul Sheer writes:

> 

> >but you know about these reports because... you are psychic?

> 

> Because it happens to be something I have worked with for many years.

> 

> You may find these two papers relevant to my credentials:

> 

> 	http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.7547

> 

> 	http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.6775

> 

> 



These excellent papers say almost nothing about leap seconds
except that you don't like them.

   
    [...] that user input or software upgrades are necessary
    to instruct the calendar functionality about
    upcoming leap seconds.


Pr'aps calander programs needing user input or upgrades
is only a problem with those calander programs. Actually,
a bigger problem is that an OS asks for the time AT ALL,
like during the install: why would it need to when there
is an NTP network? Because there is no definitive way of
locating the best NTP server.

Myself I'd like to rather fix that *that* *bigger* problem.

Since you were implementing an NTP server in any case,
may I ask why did you not build into the NTP server the
extras people may need to solve these other problems?
...say as "extensions" to the standard.

At the very least, UTC-SLS is an obvious solution
that fixes the problem for 99% of the remaining 1%
of companies that are actually effected by the problem.

   ntpd --utc-sls=on --utc-sls-ramp=1:10000

Hmmmm *perhaps* *there* *are* *some* *talented*
*programmers* *out* *there* *that* *will* *implement*
*this* one* *day*.



> >sounds like UTC-SLS solves this problem - no?

> 

> It's mostly a paperwork problem: it's cheaper to pause production

> than [...]

> 


the way you put it, it doesn't sound like a widespread issue

-paul