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

[Marek Behun <kabel@xxxxxxxxxxxx>]

On Sun, 9 Feb 2014 09:26:58 -0800 (PST)
Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

> 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
> 

Hi,
I think there is a little misunderstanding here. I do not want to not
use leap seconds. I fully understand why they are applied and how the
systems work now. Again I suggest to read the first post at
http://forums.gentoo.org/viewtopic-t-980486.html where this idea is
explained more. I want to use another definition of UNIX time.

Current definition of UNIX time is this:
  the number of seconds that have elapsed since 00:00:00 Coordinated
  Universal Time (UTC), Thursday, 1 January 1970, not counting leap
  seconds.
From Wikipedia: due to its handling of leap seconds, it is neither a
linear representation of time nor a true representation of UTC. 

I want to use this redefinition:
  number of seconds that have elapsed since 00:00:00 UTC, Thursday, 1
  January 1970, *counting leap seconds*.

Currently I'm using openrdate with -c flag to do this. This way I can
use the right/Europe/Prague timezone and still have the same output of
  $ date
as is on a server with posix/Europe/Prague at that exact moment if that
server doesn't use this kind of leap seconds corrections.

To conclude: I don't want to remove leap seconds. I want my UNIX
time ticks to tick continuosly, so when a leap second occurs, my UNIX
time won't stop for one second (or skip one), it will tick normally
through that leap second and the right/Europe/Prague timezone will then
compute the right time when formatting to human readable form. That way
I can for example compute the correct number of seconds elapsed between
two events. (And please don't tell me to use CLOCK_MONOTONIC, I am
talking about events happening on different machines and this is still
an example).

The implementation should be trivial: if the flag is present, count the
number of leap seconds from a leap second database and add that number
to the time received from time server. Openrdate does exactly that with
-c flag. But openrdate cannot synchronize from more timeservers and
uses settimeofday, so time update can still be non-continuous.

From the last post on that gentoo forum page:
  This idea was presented at the first Future of UTC meeting in 2011,
  and the problems faced by Linux kernels were documented at the second
  meeting in 2013. See http://futureofutc.org/ for the full conference
  proceedings, and see
  http://www.ucolick.org/~sla/leapsecs/right+gps.html for more about
  the code that can test this idea.

Marek Behun

Attachment: signature.asc
Description: PGP signature