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

Falsehoods programmers believe about Unix time

alexwlchan.net

Post reply on HN
Print view View original

131–140 of 275 posts

Re: Falsehoods programmers believe about Unix time

#131

Post by twic »

bradknowles wrote: post #96
endymi0n wrote: post #36

Earlier quoted context omitted.

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 third principle of Continuous Delivery is "If something is difficult or painful, do it more often". So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds. OTOH, if you think leapseconds are painful now, just you wait until you postpone this pain and do it even less frequently.

That principle is more of a koan than actual concrete advice.

For example, deleting your entire codebase and firing all your developers is painful, but even the most continuous deliverer wouldn't advise you to do that more often.

Re: Falsehoods programmers believe about Unix time

#132

Post by twic »

shados wrote: post #111
endymi0n wrote: post #36

Earlier quoted context omitted.

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…

I know it will never happen because of cultural reasons, but really, we need to separate the time (as in how I describe a point on the time scale, for, let say, a meeting, especially one that involves people in globally distributed locations), and the cultural aspect (at what time people are sleeping or eating lunch). Right now those two things are intertwined, and that's bad. Not everyone eats lunch around noon or g…

Swatch Internet Time:

https://en.wikipedia.org/wiki/Swatch_Internet_Time

Re: Falsehoods programmers believe about Unix time

#133

Post by twic »

jhayward wrote: post #45
ergothus wrote: post #38

Earlier quoted context omitted.

> The different time definitions exist to support different use cases. UTC isn't flawed, in fact the adjustments that keep it aligned to solar time are very helpful for its defined use cases. The user above listed several explicit cases that seem needlessly complicated. Can you give examples where the adjustments to UTC are so helpful for its defined use case? Or elaborate what that case is? I'm not trying to be obst…

We humans almost always want our concept of "what time is it" to correspond to the relative motion of the sun in the sky. We ask "what time is sunrise?", and "when will the days start getting longer?". We like "noon" to be when the sun is highest in the sky. All those things are what UTC is designed for.

We humans, without the use of a clock, do not have the faintest idea when midday or midnight is. We can't judge when the sun is highest in the sky, and we certainly can't judge when it's lowest under our feet.

The sun isn't even highest in the sky at noon! Firstly because of timezones (your noon is based on highest-sun in the middle of your timezone, not your current longitude), and secondly because of this whole epicyclic botheration:

https://en.wikipedia.org/wiki/Equation_of_time

Re: Falsehoods programmers believe about Unix time

#134

Post by jhayward »

speleo_engr wrote: post #124
jhayward wrote: post #122

Earlier quoted context omitted.

> The first step is always converting from UTC to TAI I believe you are actually converting to Terrestrial Time. If there is a correction of TAI+32.184 seconds in your calculation, that would indicate TT.

Yes, it is ultimately TT. The order goes: UTC -> TAI -> TT I could argue the TAI to TT is the second step. But let's put the pedantry aside: Is your best answer of something made easier in the modern world by leap seconds ensuring that solar noon happens at exactly 12:00:00 four times a year on an exact line of longitude for the time zone? And 4 times a year would require a time zone that does not honor daylight time…

> I'm not some crackpot here talking about the absurdity of leap seconds

No question about that; leap seconds have been controversial since they were invented. The question is whether "the juice is worth the squeeze" which is of course an opinion rather than a fact.

The nice thing about time standards of course is that there are so many to choose from. All of them have flaws when you try to use them the way we do in civil time applications.

Re: Falsehoods programmers believe about Unix time

#135

Post by PureParadigm »

Leap seconds definitely add way more complexity/uncertainty when dealing with timestamps in the future. I once made a program that would output the amount of time remaining until some time in the future (with the future time represented as a Unix timestamp). I realized that it is simply not possible to report the number of seconds until an event >6 months in the future because we simply don't know if there might be a leap second or not between now and the time in the future. Perhaps the best approach for users would be to smear any leap seconds that are announced so it never has a hard jump, but it's still not ideal because if you really want to count down to the future time you simply can't.

Re: Falsehoods programmers believe about Unix time

#136

Post by AgentME »

ddlatham wrote: post #118
AgentME wrote: post #46

Here's a falsehood I've seen a bunch of times: the idea that Unix timestamps need to be converted to your local timezone. Unix timestamps are the number of seconds since a specific date in a specific timezone (UTC)! If a user gives you a Unix timestamp and you know they're in the PDT timezone, you should not add or subtract 7 hours of seconds to "convert" the timestamp to UTC! It already is. Similarly, if your client…

Unix timestamps have no inherent time zone at all. They are a quantity of seconds (ignoring leap seconds & relativity) since a specific instant. That instant in time happens to conveniently line up with 1970-01-01T00:00 when described in UTC to make things easy for us. But it is equivalently defined as 1969-12-31T16:00-08:00 when described in another time zone. The elapsed quantity of seconds since that instant does…

I think that's a better way of putting it. The main lesson is that there's no operation called "changing the timezone of a Unix timestamp", and any code trying to do that is wrong. A date string is a function of a Unix timestamp and a timezone, and if you need to change the timezone, you need to pass a different timezone parameter, not try to do something to the Unix timestamp part.

Re: Falsehoods programmers believe about Unix time

#137

Post by wglb »

Semiapies wrote: post #8
koala_man wrote: post #4

> But it’s unsatisfying to say “this is false” without explaining why Got my upvote. I can't stand the "falsehoods programmers believe" articles that make a point out of not backing up any of their claims.

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.

Re: Falsehoods programmers believe about Unix time

#138

Post by btilly »

philwelch wrote: post #126
endymi0n wrote: post #36

Earlier quoted context omitted.

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…

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 eventually, and I would be surprised if it lasted as long.

Re: Falsehoods programmers believe about Unix time

#139

Post by isostatic »

airstrike wrote: post #19
jlv2 wrote: post #13

The author uses graphs with quarter-second increments because they make it look weirder. It's not that weird for time to standstill for 1 second.

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?

Re: Falsehoods programmers believe about Unix time

#140

Post by AgentME »

tus87 wrote: post #76
pteraspidomorph wrote: post #72

Earlier quoted context omitted.

If I understand what people are saying correctly, this is actually not true; leap seconds can not be referenced in Unix time and are not included in the unix timestamp value. They're just ghost seconds during which the counter stopped for one second. Which is not the way the system should have been designed, in my humble opinion. All seconds should be referenceable.

> leap seconds can not be referenced in Unix time UNIX time does not represent/reference calendar time, it represents the number of physical seconds since 1970-01-01UTC. How you translate that into local calendar time is up to you!

Isn't this the opposite of what the article says?
Post reply on HN