Re: [chrony-dev] Fw: leap seconds correction

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Sun, 9 Feb 2014, Marek Behun wrote:

> Hello.
> I would like to see a new feature in chrony. In accordance to
> http://www.ucolick.org/~sla/leapsecs/right+gps.html , something like
> openrdate's -c flag:
>
>  Correct leap seconds.  Sometimes required when synchronizing to an
>  NTP server.  When synchronizing using the RFC 868 protocol, use this
>  option only if the server does not correctly account for leap
>  seconds.  You can determine if you need this parameter if you sync
>  against an NTP server (with this parameter) or (recommended) check
>  with a local radio controlled watch or phone service.
>
> That is, I want to use right/something timezone as my system timezone
> even if the server that I'm synchronizing from a timeserver that uses
> posix timezone. You can see some explanation of "right UNIX time" at
> http://forums.gentoo.org/viewtopic-t-980486.html

ntp and chrony do not do timezones. They always operate on UTC. Since UTC is
the same everywhere in the world, by definition, there is no problem of
"different timezones" to be fixed.

The leapseconds is another issue. The world, and ntp are designed around UTC.
UTC contains leapseconds. There are a few "nuts" who would like the civil time
not to contain leapseconds, who do not mind if in a few years (well petenia)
noon occurs when the sky is dark, and midnight when the sun is high in the
sky. I do not think that anyone either in the ntp community or in the chrony
community is going to go to great effort to cater to this "fringe". There is
nothing in the ntp protocol which would enable one to know which servers serve
UTC and which some other definition of time. 
The "ignore leapseconds" is purely how time is handled at the time of the
leapsecond. soem servers will warn a day, a week, a month ahead of time that a
leapsecond is coming. This causes an ntp server to insert/delete a leapsecond
at the end of the month. But some servers are wrong. So that the local system
does not by mistake insert a leapsecond, ntp can tell it not to. But this has
NOTHING to do with how it handles time. If that server then behaved as though
a leapsecond had occured. it will server the wrong time thereafter and ntp
will follow that wrong time (assuming say that is the only server or almost
all of the servers it follows are the wrong time). Ie, the ignore leapsecond
flag does NOT treat those servers any differently as far as the time
interchange is concerned. It ONLY treats them differently as far as whether or
not to insert a leap second.

I am afraid if you want to follow that "cult" you will have to rewrite all
your time server routines yourself.

(Yes, I know I am using pejorative terms to describe a serious position. But 
then so did you by calling that position "right". I
happen to think they are as wrong as those who would advocate keeping our
present seconds but putting 100 sec to the min, 100 min to the hour and 10
hours to the day, and saying "so what if on some days the sun at noon is high
in the sky and on other days it has set-- what has time to do with the sun".
It is a possible position to take. But it is far far from the majority and if
far far from convincing a majority. One should equally simply make the year
400 days long, and to hell with the problem that sometimes Christmas falls
when there is snow on the ground and sometimes when it is hot. What has time
to do with the seasons?)

Note Unix uses UTC. There is no special Unix time. And I believe it is good to
be reminded occasionally that we live in the world which was not created for
eaze of machines, but has idiosyncracies. After all it was believing that that
world could be recast into a convenient mechanized image that led to the
global warming problem, etc.

> Is this possible?
Possible? sure. Is anyone going to do it? Probably not.


> Marek Behun

--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.