Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UTC vs. UT1 time and other nuances (2020)

mperdikeas.github.io

Post reply on HN
Print view View original

11–20 of 35 posts

Re: UTC vs. UT1 time and other nuances (2020)

#11

Post by bxparks »

Even more confusing, the time printed by our computers may appear to be UTC, but is probably POSIX (or Unix) time. It is very close to UTC but ignores leap seconds. https://en.wikipedia.org/wiki/Unix_time

During a positive leap second, the POSIX second repeats itself (an alternative mental model could be that the given POSIX-second lasts 2 UTC-seconds). During a negative leap second, the given POSIX-second disappears (or alternatively, the given POSIX-second lasts 0 UTC-seconds).

On my Ubuntu box, the `date +%s` command prints the number of POSIX seconds since 1970-01-01, not the number of UTC seconds since 1970-01-01. To get the number of UTC seconds, we must add the number of intervening leap seconds since 1970-01-01.

I get a headache every time I have to think about this.

Re: UTC vs. UT1 time and other nuances (2020)

#12

Post by jabl »

euroderf wrote: post #10

How in the world did astronomers & their software developers manage to push off onto the rest of the software world (and society at large) the atrocious concept of leap seconds.

UT1 might not work for engineering applications with tight tolerances, as the length of a UT1 second varies.

Personally, in my non-expert opinion, we should stop adding or subtracting leap seconds from UTC (that is, UTC would thereafter be at a constant offset from TAI), and leap seconds would instead be added to the timezone DB. That way local time (like Aug 14 2022 xx:53) would still retain the familiarity with 12:00 being noon, at least at some point in each timezone, but calculations with UTC seconds would not need to bother with leap seconds.

Re: UTC vs. UT1 time and other nuances (2020)

#13

Post by jillesvangurp »

bxparks wrote: post #11

Even more confusing, the time printed by our computers may appear to be UTC, but is probably POSIX (or Unix) time. It is very close to UTC but ignores leap seconds. https://en.wikipedia.org/wiki/Unix_time During a positive leap second, the POSIX second repeats itself (an alternative mental model could be that the given POSIX-second lasts 2 UTC-seconds). During a negative leap second, the given POSIX-second disappears…

Your computer periodically syncs with other computers to compensate for the time drift. Posix is just an API and a set of conventions. What your computer syncs with (typically via NTP), is a bunch of very precise clocks. Without that, you'd have a lot of time drift. The reason POSIX ignores leap seconds is because a leap second is well below the margin of error that most computer clocks have. They simply are not precise enough. Without syncing they'd be drifting apart many seconds within days/weeks probably.

That's also why the leap second correction is not a big deal because it just happens when computers sync. A few seconds correction is just a routine correction. Happens all the time.

Re: UTC vs. UT1 time and other nuances (2020)

#14

Post by denton-scratch »

> Essentially, UTC is a compromise devised to satisfy the needs of two communities of users:* Astronomers and navigators, * Physicists and engineers

I think author is wrong about astronomers, for whom UTC is an unwanted complication. Astronomers use sidereal time, which is unrelated to ther apparent motion of the sun. For short intervals, physicists and engineers may as well use atomic time.

The WP article on UTC has a section titled "Rationale", but doesn't explain what problems/compromises UTC was supposed to address. It's worthy of note, however, that of the three bodies involved in the first version of UTC, two were national naval observatories.

Re: UTC vs. UT1 time and other nuances (2020)

#15

Post by jeroenhd »

jillesvangurp wrote: post #13
bxparks wrote: post #11

Even more confusing, the time printed by our computers may appear to be UTC, but is probably POSIX (or Unix) time. It is very close to UTC but ignores leap seconds. https://en.wikipedia.org/wiki/Unix_time During a positive leap second, the POSIX second repeats itself (an alternative mental model could be that the given POSIX-second lasts 2 UTC-seconds). During a negative leap second, the given POSIX-second disappears…

Your computer periodically syncs with other computers to compensate for the time drift. Posix is just an API and a set of conventions. What your computer syncs with (typically via NTP), is a bunch of very precise clocks. Without that, you'd have a lot of time drift. The reason POSIX ignores leap seconds is because a leap second is well below the margin of error that most computer clocks have. They simply are not prec…

This is also why I think it's silly people make such a big deal out of leap seconds. Yes, to the programmers it would be great if time were to flow uniformly, but it doesn't, and it doesn't even stay consistent on your computer. Your time may go back and forth several seconds depending on your RTC and its conditions and leap seconds should be treated the same.

Re: UTC vs. UT1 time and other nuances (2020)

#16

Post by blahgeek »

jabl wrote: post #12
euroderf wrote: post #10

How in the world did astronomers & their software developers manage to push off onto the rest of the software world (and society at large) the atrocious concept of leap seconds.

UT1 might not work for engineering applications with tight tolerances, as the length of a UT1 second varies. Personally, in my non-expert opinion, we should stop adding or subtracting leap seconds from UTC (that is, UTC would thereafter be at a constant offset from TAI), and leap seconds would instead be added to the timezone DB. That way local time (like Aug 14 2022 xx:53) would still retain the familiarity with 12:…

I think the problem is that we already have the networks and protocols to synchronize time (NTP, PTP, etc.), but not for timezone DB data.

Re: UTC vs. UT1 time and other nuances (2020)

#17

Post by bloak »

jabl wrote: post #12
euroderf wrote: post #10

How in the world did astronomers & their software developers manage to push off onto the rest of the software world (and society at large) the atrocious concept of leap seconds.

UT1 might not work for engineering applications with tight tolerances, as the length of a UT1 second varies. Personally, in my non-expert opinion, we should stop adding or subtracting leap seconds from UTC (that is, UTC would thereafter be at a constant offset from TAI), and leap seconds would instead be added to the timezone DB. That way local time (like Aug 14 2022 xx:53) would still retain the familiarity with 12:…

If people don't like leap seconds, there is no need to redefine UTC; they can just use TAI today. That gives them the additional advantage of not having to handle leap seconds in the past, because software that handles historical UTC timestamps will always need to know about the leap seconds that have already happened.

Re: UTC vs. UT1 time and other nuances (2020)

#18

Post by zokier »

euroderf wrote: post #10

How in the world did astronomers & their software developers manage to push off onto the rest of the software world (and society at large) the atrocious concept of leap seconds.

Not astronomers but naval navigators. UTC is direct descendant of time signals broadcast by naval observatories as a companion for their naval almanacs. It ended up as general civil time pretty much because it was there and there wasn't much competition around.

Besides when UTC was standardized and adopted in the sixties, software wasn't really much of a concern

Re: UTC vs. UT1 time and other nuances (2020)

#19

Post by zokier »

jillesvangurp wrote: post #13
bxparks wrote: post #11

Even more confusing, the time printed by our computers may appear to be UTC, but is probably POSIX (or Unix) time. It is very close to UTC but ignores leap seconds. https://en.wikipedia.org/wiki/Unix_time During a positive leap second, the POSIX second repeats itself (an alternative mental model could be that the given POSIX-second lasts 2 UTC-seconds). During a negative leap second, the given POSIX-second disappears…

Your computer periodically syncs with other computers to compensate for the time drift. Posix is just an API and a set of conventions. What your computer syncs with (typically via NTP), is a bunch of very precise clocks. Without that, you'd have a lot of time drift. The reason POSIX ignores leap seconds is because a leap second is well below the margin of error that most computer clocks have. They simply are not prec…

The reason why POSIX time ignores leap seconds was that it was considered simpler for userspace if you can do things like `time() % 86400` to get the time of day etc without needing to worry about leap seconds, essentially allowing userspace to be ignorant of leap seconds.

Re: UTC vs. UT1 time and other nuances (2020)

#20

Post by layer8 »

sxcurry wrote: post #3
layer8 wrote: post #2

TAI is also a kind of approximation, since time elapses differently depending on gravitational pull, due to relativistic effects. It is defined as the physical time elapsing on a geodesic, an imaginary surface covering the earth at roughly sea level with equal gravitational pull at all points. In reality, physical time elapses at slightly different “rate” depending on where you’re located on the surface of the earth…

Rather than geodesic I think you meant geoid.

You’re right of course, can’t edit it anymore.
Post reply on HN