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

91–100 of 275 posts

Re: Falsehoods programmers believe about Unix time

#91

Post by ergothus »

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.

And the leap seconds meaningfully alter that?

Re: Falsehoods programmers believe about Unix time

#93

Post by msla »

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 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.

The first thing is for time zones, inclusive of DST/Summer Time/etc. The second thing is for calendrical reform, which we've basically stopped doing now that the Gregorian calendar is as widespread as it's going to be. Leap seconds are for this:

https://tycho.usno.navy.mil/leapsec.html

> Currently the Earth runs slow at roughly 2 milliseconds per day. After 500 days, the difference between the Earth rotation time and the atomic time would be 1 second. Instead of allowing this to happen, a leap second is inserted to bring the two times closer together.

The "error" induced by the Earth slowing amounts to 12 minutes over the course of one thousand years.

Re: Falsehoods programmers believe about Unix time

#94

Post by revicon » 

  Unix time assumes that each day is exactly 86,400 seconds long (60 × 60 × 24 = 86,400), leap seconds be damned
I don't think I understand this claim. Unix time has no concept of a "day". Leap seconds increment UTC time, but doesn't add anything to the number of seconds that have elapsed since unix epoc.

Re: Falsehoods programmers believe about Unix time

#95

Post by kosievdmerwe »

duxup wrote: post #7
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.

I blame (perhaps unfairly) this idea that people write a lot of programming related articles and blogs as resume fodder, and not really for an audience beyond that. I've run across so many "how to do" and it's the same example code and you can see where it has skewed over time... and evolved into something that the author really doesn't understand. Same goes with some of the fundamentals and gee wiz "falsehoods" and…

Talking about resume fodder, my favorite is how everyone seems to have to write an article about bloom filters. Or at least every month or so someone posts an article about them on HN from their blog[1]. They're a brain dead simple data structures and a lot of times the author leaves off the actual hard bit about them: deciding how big they should be and (after reading up about them a bit while writing this comment) how many hash functions they should have.

[1] https://hn.algolia.com/?query=bloom%20filters&sort=byDate&pr...

Re: Falsehoods programmers believe about Unix time

#96

Post by bradknowles »

endymi0n wrote: post #36
speleo_engr wrote: post #14

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 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.

Re: Falsehoods programmers believe about Unix time

#97

Post by lutorm »

speleo_engr wrote: post #44
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…

Your article is about time zones, not leap seconds? The US has put forth a proposal to abolish leap seconds. It is now supported by China, Australia, Japan, and South Korea. The ITU keeps punting on actually voting on it - it's now scheduled for 2023. https://en.wikipedia.org/wiki/Leap_second A day already drifts... every single day in fact. Why is 0.9 sec the magic threshold for maximum drift? Why can't it be 1 minu…

It's a lot easier to test and prepare for something that occurs at least semi-regularly than a monumental event far into the future that is "so far into the future we don't have to worry about it"....

Re: Falsehoods programmers believe about Unix time

#98

Post by mikedilger »

speleo_engr wrote: post #14

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…

I don't mind having UTC with leap seconds, but I do mind it being the defacto standard. NTP would be more useful if it was synchronizing TAI.

Re: Falsehoods programmers believe about Unix time

#99

Post by xmprt »

throw0101a wrote: post #52
speleo_engr wrote: post #14

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…

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

Re: Falsehoods programmers believe about Unix time

#100

Post by lutorm »

ergothus wrote: post #91
jhayward wrote: post #45

Earlier quoted context omitted.

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.

And the leap seconds meaningfully alter that?

Yes. Leap seconds are there to align UTC (an atomic time) with UT1, which is defined based on mean solar time, ie "the day", since UT1 isn't uniform.

Without leap seconds, UTC will slowly drift out of sync with the Earth's rotation.

Post reply on HN