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

141–150 of 275 posts

Re: Falsehoods programmers believe about Unix time

#141

Post by dillonmckay »

013a wrote: post #78
jhayward wrote: post #29

Earlier quoted context omitted.

> come to the conclusion that UTC is flawed 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. It's just that time is complicated. If you think you will be doing time math where duration is paramount consider using TAI. PS: for all those who think 'time' is complicated in fascinat…

Well, time is complicated, but not for reasons that really matter to 99.95% of engineers (relativity and such). At its most basic level, Time is really just a monotonically increasing counter of seconds (or ms or ns or whatever). That's it. The problem is really the cultural and societal layers on top of it. That's not Time's fault, its Our fault. A "Day" has to be 1 rotation of the earth around its axis, a "Year" ha…

> Every unit of time at the Second and below is Simple. Every layer above it is Complex...

This is an excellent insight. Thanks!

Re: Falsehoods programmers believe about Unix time

#142

Post by GordonS »

btilly wrote: post #138
philwelch wrote: post #126

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…

Even if there was a leap second every year... does it matter? It would still take several hundred years for the difference to be noticeable, at which point you can just change UTC by +-1h.

Re: Falsehoods programmers believe about Unix time

#143

Post by ClassyJacket »

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…

"Changing any of these will make the summer drift into the winter, or the night into the day, or whatever."

Leap days, sure.

Leap seconds - as the article points out, there have only been 27 so far since 1970. Less than a minute per century isn't much drift, and could be corrected in a bigger block later.

Re: Falsehoods programmers believe about Unix time

#144

Post by FabHK »

msla wrote: post #77
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…

> A day is defined as the rotation of the earth around its axis. When you get into the world of programming for most people, businesses especially, a day is defined as 24 hours. We like to think that our days and months and years are tied to vast astronomical forces, for romantic reasons, but when it comes down to it, everything comes back to the second, and the second is defined to be a single unvarying length of ti…

Well, depends.

In TAI: A day is 24 hours (86400 seconds always), and a second is a SI second.

In UTC: A day is a rotation of the earth, and a second is a SI second. (And since these are incompatible, we have to introduce leap seconds).

In UT1: A day is a rotation of the earth, and a second is 1/86400 of a rotation of the earth.

Julia, interestingly, uses the UT1 notion, thus avoiding leap seconds, IIRC.

Re: Falsehoods programmers believe about Unix time

#145

Post by indigo945 »

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.

The obvious correction is to change the duration of a second such that a year is exactly $integer seconds long. While this will make the duration of second drift from year to year, that drift is so small that everyday devices like consumer-grade computers could just ignore it, provided they're NTP synced once every five years or so. Physicists can just keep using whatever they're using and call it by a different name. Ideal solution all-around.

Re: Falsehoods programmers believe about Unix time

#146

Post by IggleSniggle »

msla wrote: post #77
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…

> A day is defined as the rotation of the earth around its axis. When you get into the world of programming for most people, businesses especially, a day is defined as 24 hours. We like to think that our days and months and years are tied to vast astronomical forces, for romantic reasons, but when it comes down to it, everything comes back to the second, and the second is defined to be a single unvarying length of ti…

Well, just to nitpick, seconds do vary in comparative length from reference frame to reference frame...and that actually does start to matter in global computing.

Re: Falsehoods programmers believe about Unix time

#147

Post by dmh2000 »

just an anecdote about UTC vs GPS time. GPS time doesn't have leap seconds.

So my team was testing a system with some devices, one of which was a GPS and the main system had UTC from NTP. We had a big display that showed all our data including both times, so we could monitor what was going on. So the two displayed times were 13 seconds apart (the number of leap seconds then). Our program manager was a smart guy but gaffe prone. So in a demonstration of our system he blurted out to the whole room of observers, 'hey something is wrong, those two times are different'. We cringed and explained, but it sounded like we were covering up an error. But he would go on to repeat the gaffe again to a different group.

Re: Falsehoods programmers believe about Unix time

#148

Post by spydum »

abtinf wrote: post #53

Perhaps a stupid question: Why isn't there a time standard that is monotonic and defined simply in terms of seconds, without attempting to match the movement of the earth (no leap seconds, no negative seconds, no daylight savings, no complicated calendar politics)? If such standard existed, wouldn't it be the best to use for programming, with "simple" conversions to/from the all the other standards? Basically, I want…

I can’t WAIT until we have to deal with time dilation problems on networks and certificates.

Re: Falsehoods programmers believe about Unix time

#149

Post by IggleSniggle »

013a wrote: post #78
jhayward wrote: post #29

Earlier quoted context omitted.

> come to the conclusion that UTC is flawed 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. It's just that time is complicated. If you think you will be doing time math where duration is paramount consider using TAI. PS: for all those who think 'time' is complicated in fascinat…

Well, time is complicated, but not for reasons that really matter to 99.95% of engineers (relativity and such). At its most basic level, Time is really just a monotonically increasing counter of seconds (or ms or ns or whatever). That's it. The problem is really the cultural and societal layers on top of it. That's not Time's fault, its Our fault. A "Day" has to be 1 rotation of the earth around its axis, a "Year" ha…

Seconds are only Simple if they are defined as such. If they are defined as a subdivision of the day, then they need to be rebound to the slowing rotation of the Earth as the Earth slows and as relativistic differences due to altitude come into play.

If the second uses some other definition, you still need some centralized authority to define its length, for the same reason that it’s measurement will drift depending on your reference frame.

Re: Falsehoods programmers believe about Unix time

#150

Post by InitialLastName »

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

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 epi…

We sure can judge whether it's before or after sunset though.
Post reply on HN