On Sat, 2010-09-04 at 22:43 +0000, Poul-Henning Kamp wrote: > In message <1283634327.9574.120.ca...@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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs