Live data from Hacker News

Falsehoods programmers believe about Unix time

alexwlchan.net

181–190 of 275 posts

Re: Falsehoods programmers believe about Unix time

#181
post #152

Earlier quoted context omitted.

The only one I can think of is: determining the phase of the 24 hour day (as measured by atomic clocks) with respect to the Earth's rotation. It does seem logical use TAI for civil time. People interested in calculating the Earth's rotation to high precision could consult a regularly-updated publication somewhere. Eventually the Earth's rotation will drift out-of-sync with the atomic clock timebase, but that won't be…

Why TAI and not UT1? Who/what really cares about SI seconds?

People who want a predictable and monotonic time scale

Re: Falsehoods programmers believe about Unix time

#182
Basically, everyone who has a clue about time standards uses TAI for internal representation in non-relativisitic applications.

In other news: most software is brain-dead and most software engineers lack basic education in pretty much everything other than composing tons of terminally boring code out of a few LEGO shapes provided by programming languages.

Re: Falsehoods programmers believe about Unix time

#183

The original purpose of Unix time was decoupling local time representation and internal timekeeping of the system. Unix time could be the "One True Time" of the system, it always increases monotonically. When you need local time, all the tricky and nasty details, including DST, mandated calendar changes, etc, are processed by the tzinfo system library/database. If the calendar has changed, at least in principle one d…

> Unfortunately, Unix time did not considered the effects of leap second The change to UTC to include leap seconds was in 1972, which was after unix time came into existence.

It has nothing to do with my argument, there could be awareness, to the extents that Unix architects had seen it in the news, but still, it was not considered. I don't believe support of leap second was built into Unix and honored properly until 1990s, when NTP became prevalent.

Also, the fact that Unix time starts before leap seconds were introduced made timekeeping in TAI an even stronger point. And I'm waiting for some insights on why it's not being done.

Re: Falsehoods programmers believe about Unix time

#184

Basically, everyone who has a clue about time standards uses TAI for internal representation in non-relativisitic applications. In other news: most software is brain-dead and most software engineers lack basic education in pretty much everything other than composing tons of terminally boring code out of a few LEGO shapes provided by programming languages.

...oh, and there's also the issue of time domains and time sources having different spectral shapes of their noise.

Re: Falsehoods programmers believe about Unix time

#185
post #137

Earlier quoted context omitted.

Yeah, the standard falsehoods listicle would have ended right before that line. Timekeeping is strange. Makes me want to store everything in TAI and then convert it for display.

As is done in qmail.

Interesting—I wondered if anyone was doing that.

Re: Falsehoods programmers believe about Unix time

#186
post #138

Earlier quoted context omitted.

There have been a net +27 leap seconds since the 1970’s. That’s not enough to turn summer into winter or day into night. That’s roughly a full minute per century.

Your statement is both true and misleading. The speed of the Earth's rotation is slowing over time. Therefore leap seconds are becoming more and more common. In a century, we should be averaging something like 1 a year. In 500 years, we should be averaging one every few months. And so on. It took over a thousand years for the Julian calendar to fall apart. Our current timekeeping system will also fall apart eventuall…

500 years from now, if we're still alive, enough of us will be living in space colonies rather than on the Earth's surface that the Earth's rotation will not necessarily be immediately relevant to everyone's lives.

Regardless, we've had maybe half a minute of drift since the 1970's. If the drift is 1 minute in the 2000's, 1 second per year in the 2100's, 2 seconds per year in the 2200's, 3 seconds per year in the 2300's, etc., then by 2500, the cumulative drift would add up to...60 + 100 + 200 + 300 + 400 + 500 or 1560 seconds of total cumulative drift by 2600. That's less than half an hour. If we didn't bother accounting for leap seconds, UTC midnight would be only half an hour off from astronomical midnight in 600 years, which is roughly the same error inherent in most time zones.

Re: Falsehoods programmers believe about Unix time

#187

I read articles like this and come to the conclusion that UTC is flawed, not Unix time. Leap seconds seem mostly useless. People seem to think they are important for astronomy, but for every astronomical calculation I have ever done, your first step is converting from UTC to TAI. Move any jumps in time to once a century (or millennium). Such jumps have occurred in the past (Julian to Gregorian) and are easy to handle…

Well, the problem with this is that every simplistic view at time is... well... too simple. It's not that many people haven't tried, I especially like this article: https://qntm.org/abolish That being said, why your approach doesn't work is that there are several hard astronomical or cultural definitions that you'd throw off by playing with time. A day is defined as the rotation of the earth around its axis. A week i…

The earth doesn't travel the same course each year. It's chaotic.

Best to define a second as a certain distance light travels in a vacuum and use that to build minutes, hours, etc. Then, have a fixed geo reference point (like, say, geo 0:0) that holds an atomic clock as a main reference.

We are only really talking about local coordinate changes in the time dimension, really, so might as well simplify.

Re: Falsehoods programmers believe about Unix time

#189
Perhaps I don't fully understand the reasoning that went into these things when they were decided, but I think the following would be more sane:

- Hardware clocks track Terrestrial Time, and TT is used for timestamps and all timekeeping that doesn't care about where exactly on the planet you are

- Leap seconds are treated as part of the timezone data. UTC is treated as just another timezone, with the appropriate leap second offset given by the timezone data for that date and time

- NTP keeps hardware clocks synchronized to TT and also carries updates to timezone data (including leap seconds)

This doesn't solve the problem of hardware clocks jumping backwards or forwards in time - hardware clocks can drift or be misset etc. and be updated - but I can't help but thinking that much of the pain around time and timezones is caused by basing our timekeeping on UTC rather than TT.

Re: Falsehoods programmers believe about Unix time

#190
post #99

Earlier quoted context omitted.

Some people think one year is one orbit around the sun, and not exactly 365 days. Leap years help to keep that reality. Some people think that a day is one revolution of Earth's axis, and not exactly 86400 seconds. Leap seconds help to keep that reality. The fact that axial rotation is less predictable than orbital paths is a quirk of nature.

Leap years have pretty straightforward rules for when they happens. Approximately every 4 years, expect on 100 years, except on 400 years. Leap seconds on the other hand happen at the whim of the IERS

Leap years are actually just slightly inaccurate. Leap years estimate an orbital period of 364.2425 days but the actual orbital period is 365.24217 days.

Also, it should be noted that basically nobody actually understands a "year" to mean an orbit of Earth around the Sun relative to the Local Standard of Rest, which is called a sidereal year (ca. 365.256 days). Instead, to most people, a year means a cycle of seasons which recreates the same angle between the Earth-Sun axis and the Earth's axial tilt, which generates seasonal temperatures and is called a tropical year. Because the axial tilt is variable, the tropical year also varies and eventually drifts away from the sidereal year. The tropical year and sidereal year differ by about 20 minutes, so today's year starts about a month "away" from the year Julius Caesar enacted the first true solar calendar.

The difficulty in this case is that spinning rocks in space can float around however they please.

Post reply on HN