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 Desktop Packages, which is subscribed to gnome-control-center 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 -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
