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

51–60 of 275 posts

Re: Falsehoods programmers believe about Unix time

#51

Post by someguydave »

speleo_engr wrote: post #37
labster wrote: post #27

Earlier quoted context omitted.

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

The only one I can think of is: determining the phase of the 24 hour day (as measured by atomic clocks) with respect to the Earth's rotation.

It does seem logical use TAI for civil time. People interested in calculating the Earth's rotation to high precision could consult a regularly-updated publication somewhere. Eventually the Earth's rotation will drift out-of-sync with the atomic clock timebase, but that won't be important until we accumulate several minutes/hours of error from TAI which could be centuries from now.

Re: Falsehoods programmers believe about Unix time

#52

Post by throw0101a »

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.

Re: Falsehoods programmers believe about Unix time

#53

Post by abtinf »

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 a monotonic clock that starts at an arbitrary point (I would suggest Isaac Newton's birthday), is able to go all the way back to the big bang, and forward until the heat death of the universe, with millisecond or better precision.

Re: Falsehoods programmers believe about Unix time

#54

Post by endymi0n »

m1el wrote: post #41
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…

> 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 This has nothing to do with leap seconds. Leap seconds are the worst mechanism in keeping time, there's not a single advantage to having leap seconds. > A day is defined as the rotation of the earth around its axis. And we can n…

> Yeah, and it will take a millennium for Earth rotation to shift enough for people to notice it. On the other hand, you'd have no problem with summer/winter time I presume?

No, I don't, as they are just views on a monotonically increasing time scale named UTC that keeps up with Earth's rotation, so that every single thing from climate diagrams to everything else humanity is syncing on keeps working and being comparable.

> We can still use timezones to fix the shift.

Or, we could not do that. Everyone is free to use TAI inside their own projects as they see fit if they have the needs for strictly monotonically increasing time. I would argue that leap second smearing has way less artifacts in practice than bolting time zones onto a shifting UTC time.

Re: Falsehoods programmers believe about Unix time

#55

Post by jhayward »

planteen wrote: post #39
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…

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

See my comment on the other reply.

I'll add in; astronomers like to be able to find objects in the sky using calculations based on time. UTC (actually TT, which underlies UTC) is good for that.

Spend a little time on the various wiki pages for time standards, and think about why those things exist.

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

Re: Falsehoods programmers believe about Unix time

#56

Post by endymi0n »

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…

That's interesting, I stand corrected. TIL that it's actually a heavily disputed topic and much less clear than I painted it, I had quite a different impression before — thanks!

Re: Falsehoods programmers believe about Unix time

#57

Post by toast0 »

tus87 wrote: post #31

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…

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

> 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

Unix time is NOT the number of physical seconds since 1970 UTC. It's the number of Unix Seconds since 1970. Every day has 86400 Unix Seconds. Some UTC days have more than 86400 physical days. Unix time cannot represent the seconds beyond 23:59:59 on a UTC day, but otherwise attempts to match UTC.

Re: Falsehoods programmers believe about Unix time

#58

Post by petschge »

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…

Usually the first step is to correct from what ever the local clock at the observatory said to actual UTC.

Then you convert from UTC to TAI.

And then you convert from TAI to the arrival time at the solar barycenter, removing the geometric light travel time to Earth (or more precisely the observatory) as well as the gravitational effects of Sun, Jupiter and Earth.

Re: Falsehoods programmers believe about Unix time

#59

Post by bassman9000 »

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…

I wouldn't be surprised if someone told me 10-15% of our bugs were because of Eng/PM misunderstanding this.

Re: Falsehoods programmers believe about Unix time

#60

Post by seaish »

nulagrithom wrote: post #18

I don't understand this one: > If I wait exactly one second, Unix time advances by exactly one second How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds. I feel like this is wrong too: > If there’s a leap second in a day, Unix time either repeats or omits a second as appropriate to make them match. It's not Unix time doing that. It's UTC.

Unix time is based on a hard calculation of UTC seconds, minutes, hours, days, and years. So UTC jumping causes a discontinuity in Unix time.

Im pretty sure the second graph is mislabeled (the UTC second after 23:59:60 should be 00:00:00), but Unix time takes 23:59:60 to mean the same as 00:00:00. So 23:59:60.5 is also the same as 00:00:00.5, and so on. If you parsed the Unix time into a readable timestamp, it would tell you it's the first second of the next day for two seconds.

Post reply on HN