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

31–40 of 275 posts

Re: Falsehoods programmers believe about Unix time

#31

Post by tus87 »

This guy is confusing Unix time with local time. This statement:

> Unix time is the number of seconds since 1 January 1970 00:00:00 UTC

Is true regardless of the calender or leap seconds. Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar. Converting Unix time to local time obviously has to take that into account, but we still need an absolute measure of our progress does the timeline which is what Unix time provides.

This is why we use Unix time, it's the same everywhere and nothing short of relativity can affect it.

Re: Falsehoods programmers believe about Unix time

#32

Post by Verdex »

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 have a theory that simple sets can become difficult to understand not because of anything in their nature, but because of how they are desired to be consumed.

In other words, if you have a simple to understand thing, then it might become hard to understand if it needs to be fed into something that is itself hard to understand. (Or even if the way in which you feed it into the other thing is hard to understand).

Additionally, if you have something which is easy to understand that is fed into multiple incompatible things (either the things are easy to understand or hard to understand), then the whole system becomes harder to understand.

Finally, if the starting point that is fed into all other things is not actually easy to understand but in fact hard to understand ... things can get pretty bad.

Even if time was easy to understand by itself, then I still think it would be pretty hard to deal with because it is used for multiple incompatible domains (astronomical vs how long a day is on earth for example).

Re: Falsehoods programmers believe about Unix time

#34

Post by aflag »

rusbus wrote: post #10

Is it also possible for Unix time to go backwards with NTP? I assume that's much more common in practice than leap seconds?

ntpd will only move the clock backwards if the gap is too big and you run a command. Otherwise, it will only slow down the clock and possibly alert you that it's having trouble catching up.

Re: Falsehoods programmers believe about Unix time

#36

Post by endymi0n »

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 is a hard cultural and religious boundary for just about everything in life.

A month is roughly the rotation of the moon around the earth (although that definition is arguably the weakest and ready to go)

A year is defined as the rotation of the earth around the sun.

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

Time just isn't simple, and although most of these intervals _almost_ fit within each other, reality is that they don't and we'll always have artifacts.

If you enjoy philosophy on these kinds of imperfections as much as I do, I can heavily recommend this article about musical tuning: https://blogs.scientificamerican.com/roots-of-unity/the-sadd...

Re: Falsehoods programmers believe about Unix time

#37

Post by speleo_engr »

labster wrote: post #27
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…

Leap seconds are useful if you're an astronomer. Astronomers have always determined the current time. Therefore, we all get leap seconds.

How are leap seconds useful if you are an astronomer? I am genuinely curious what problem in the year 2019 is easier due to leap seconds.

I have worked on code that needed to do astronomical calculations to do things like:

position of sun, moon, Mars, Earth, and spacecraft

ECI ECEF

All of these depend on a conversion from UTC to TAI. It's covered in books like Astronomical Algorithms in the intro: https://www.willbell.com/math/MC1.HTM

Re: Falsehoods programmers believe about Unix time

#38

Post by ergothus »

jhayward wrote: post #29
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…

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

> 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 obstinate - it's just that without examples your response boils down to "No it's not" without further support. I'm open to being convinced...convince me.

Re: Falsehoods programmers believe about Unix time

#39

Post by planteen »

jhayward wrote: post #29
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…

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

"UTC isn't flawed, in fact the adjustments that keep it aligned to solar time are very helpful for its defined use cases."

What use case in the year 2019 is made easier by UTC getting leap seconds instead of treating it as a monotonically increasing scale (TAI)? I'm genuinely interested. The only suggestion I have ever heard is use of a sextant -- what an anachronism in the modern world...

Re: Falsehoods programmers believe about Unix time

#40

Post by jhayward »

brmgb wrote: post #26

I deeply disagree with point 3. Unix Time actually never goes backward: it just stagnates during a leap second. The article uses fictional fractional second to argue the contrary but I don't think it makes much sense. Unix Time is represented an integer and has no concept of such a fractional unit. That's an important distinction because it means that if you use Unix Time as a timestamp you can actually be sure than…

You can set unix time to any value, including the future or past. If timestamps are recorded during those time-traveling epochs you will indeed see time go backward. Anyone writing time-aware processing needs to take this in to account, or they will eventually suffer for it.
Post reply on HN