[Bug 970966] Re: UTC is incorrectly implemented; it does not handle leap seconds

[James Haigh]

UTC is uniform but discontinuous. If someone wanted to precisely and
reliably measure time between to points, they would need a uniform,
continuous standard such as TAI.

TAI can be implemented using the defined relation:
TAI = UTC + 10s + Announced leap seconds since 1972 (Published here: http://maia.usno.navy.mil/ser7/tai-utc.dat)

(24 leap seconds so far)

So if UTC incorrectly fails to insert a leap second, TAI would appear to
skip a second. I could therefore incorrectly measure a 25ms time
interval as 1025ms.


I could also implement UT1 (which is continuous but non-uniform) by the defined relation:
UT1 = UTC + DUT1 (Published here: http://maia.usno.navy.mil/ser7/finals.all)

See: https://en.wikipedia.org/wiki/DUT1

Again, if UTC incorrectly fails to insert a leap second, UT1 would
appear to skip a second, and incorrectly be discontinuous.


See IERS who publish the astronomical data and announce leap seconds:
http://www.iers.org/
http://maia.usno.navy.mil/


Anyway, how does it make sense to sync a clock over the network to high precision using time protocols, when the system's UTC can't even be relied on to a precision of a second?

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/970966

Title:
  UTC is incorrectly implemented; it does not handle leap seconds

Status in “gnome-control-center” package in Ubuntu:
  Invalid
Status in “util-linux” package in Ubuntu:
  New

Bug description:
  UTC ticks SI seconds in step with TAI (International Atomic Time), but
  in order to keep in sync with UT1 which is defined by the earth's
  rotation, UTC is occasionally adjusted. In other words, in order to
  keep UTC 00:00:00 within a second of midnight at the Prime Meridian,
  leap seconds are added.

  See: https://en.wikipedia.org/wiki/Leap_second

  So I tested it.

  I booted a live copy of Natty and went for a historic leap second:

  date --rfc-3339=seconds -s '2008-12-31 23:59:54+00:00'; hwclock -w
  while true; do date --rfc-3339=ns; sleep 0.25; done >> /mnt/time.log

  time.log:
  2008-12-31 23:59:57.753497430+00:00
  2008-12-31 23:59:58.006601830+00:00
  2008-12-31 23:59:58.259626718+00:00
  2008-12-31 23:59:58.512632697+00:00
  2008-12-31 23:59:58.765677765+00:00
  2008-12-31 23:59:59.018668172+00:00
  2008-12-31 23:59:59.271679983+00:00
  2008-12-31 23:59:59.524653233+00:00
  2008-12-31 23:59:59.777697760+00:00
  2009-01-01 00:00:00.030698916+00:00 <-- Where is the leap second?
  2009-01-01 00:00:00.283682058+00:00
  2009-01-01 00:00:00.536682453+00:00
  2009-01-01 00:00:00.789704596+00:00
  2009-01-01 00:00:01.042716625+00:00
  2009-01-01 00:00:01.295720967+00:00
  2009-01-01 00:00:01.548714966+00:00
  2009-01-01 00:00:01.801750574+00:00
  2009-01-01 00:00:02.054801900+00:00
  2009-01-01 00:00:02.307836286+00:00
  2009-01-01 00:00:02.560842969+00:00
  2009-01-01 00:00:02.813878513+00:00
  2009-01-01 00:00:03.066923251+00:00
  2009-01-01 00:00:03.319920865+00:00

  So either there should be a 23:59:60 leap second, or the system
  timezone should not be called UTC, but the more ambiguous term
  'Universal Time'.

  I also tried 1998 and 2005. A leap second has been announced for this
  June 30.

  I think that issues with time can potentially cause or trigger serious
  bugs elsewhere. So I'm marking this as a security vulnerability just-
  in-case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/970966/+subscriptions