Live data from Hacker News

Falsehoods programmers believe about Unix time

alexwlchan.net

271–275 of 275 posts

Re: Falsehoods programmers believe about Unix time

#271
post #268

Earlier quoted context omitted.

People who want a predictable and monotonic time scale

SI seconds (in UTC) lead to leap seconds. With UT1, "1/86400 of a day" seconds lead to a predictable and monotonic time scale.

Unfortunately, electronic devices come with quartz crystal resonators, or rubidium or cesium resonators. After frequency calibration these will keep stable time relative to the atomic clock timebase.

There is no device available that allow you to derive a clock from the relative motion of the sun about the Earth’s axis, such that the changing definition of days and seconds relative to realizable clocks can be tracked.

Furthermore it’s kind of nice to have a stable and standard definition of seconds and days. For instance, under the “ut1 system” you don’t know how long a present second is until the present day’s final observations are made.

Re: Falsehoods programmers believe about Unix time

#272
post #247

Earlier quoted context omitted.

The international date line isn't straight in order to avoid land. Moving it would be problematic.

think of it as ordinal: you're shifting left 1 unit, not moving the line, per se.

The other boundaries are a lot straighter.

Imagine what would happen when the International Date Line ends up in the middle of the US.

Re: Falsehoods programmers believe about Unix time

#273

Earlier quoted context omitted.

It's almost as if we've tried something like that in the past, and the effort to avoid the worst issues was a monumental effort.

Confess I'm not quite clever enough to know what you mean or to what you're referring.

Y2K problem, because someone at some point decided that two digits was enough to represent years. Thus when 99 came to an end, the clock would show 00 for year. It was an undefined behavior how to interpret it.

The event was rather boring, because a huge effort went into making sure that critical infrastructure was "Y2K Ready".

So my point was that pushing the problem in front of us until it becomes too large to ignore, is not a good strategy when we're talking (it) infrastructure. Handling leap seconds every now and then are the lesser evil.

Re: Falsehoods programmers believe about Unix time

#274

Earlier quoted context omitted.

Who cares if we're off by 1 second so long as we're all off by the same amount? Maybe we should all wait until this lag adds up to 1 minute before we adjust things instead of perpetually reaching for abstract perfection

Or conversely why don't we add leap deciseconds, or centi or milliseconds?

It seems to me that the one-second adjustment is exactly the right compromise. It's small enough to be ignored for most practical purposes (many clocks are out by a second anyway), and it means that the offset between TAI and UTC is a round number (37 s rather than 36.852 s), while leap seconds are frequent enough for people to get a bit of practice at handling them, while rare enough that you can avoid them if you're not confident about handling them: don't schedule any rocket launches for 00:00 on Jan 1 or Jul 1. It seems exactly right to me.

Re: Falsehoods programmers believe about Unix time

#275
post #170

Earlier quoted context omitted.

Seconds don't vary, your approximation of a second varies. If you want to nitpick, you're going to need to start with Cesium-133 oscillation periods as averaged from over nine billion samples.

Seconds do vary because there are no privileged reference frames in the universe. You'll get a different measurement if your cesium measuring experiment is traveling at a different speed than you are.

That's the direction of your mass-energy vector, not seconds.

A bit like complaining that UTC is wrong because it doesn't match your local Solar time.

Post reply on HN