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

151–160 of 275 posts

Re: Falsehoods programmers believe about Unix time

#151

Post by FabHK »

ergothus wrote: post #38
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…

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

I think most applications (including computers, except GPS receivers internally) should just switch to UT1. A rotation of the earth takes a day, and a day has 86400 seconds. Done. (Fine, a second is not exactly an SI second, but close enough for most practical purposes, and computers can handle it.)

Re: Falsehoods programmers believe about Unix time

#152

Post by FabHK »

someguydave wrote: post #51
speleo_engr wrote: post #37

Earlier quoted context omitted.

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…

Why TAI and not UT1? Who/what really cares about SI seconds?

Re: Falsehoods programmers believe about Unix time

#153

Post by tus87 »

toast0 wrote: post #89
tus87 wrote: post #73

Earlier quoted context omitted.

Unix seconds ARE physical seconds. > Every day has 86400 Unix Seconds. Except a day with a leap second in it. > Unix time cannot represent the seconds beyond 23:59:59 on a UTC day, but otherwise attempts to match UTC. Err...it literally represents ~49 years beyond 23:59:59 on Day1 of UTC.

What's the Unix Time for the UTC second 1985-06-30 23:59:60? My understanding is this physical second is not representable in unix time. How about the UTC seconds before and after that one, 1985-06-30 23:59:59 and 1985-07-01 00:00:00? My understanding is that the first is 489023999, and the second is 489024000. There is one unix second, but two physical seconds between the start of the two times.

> What's the Unix Time for the UTC second 1985-06-30 23:59:60? My understanding is this physical second

That's not a physical second, it's a calendar second.

Re: Falsehoods programmers believe about Unix time

#154

Post by FabHK »

acqq wrote: post #117

The article is wrong or misleading. POSIX (and ISO) time_t is not supposed to "see" the additional leap second at all. POSIX time_t is defined to effectively always have exactly 86400 seconds per day, and no fractional parts. The seconds as defined by POSIX then can't last exactly as long as the atomic seconds. Even on the days where a leap second occur. Wikipedia article confirms: "Every day is treated as if it cont…

Agree. In other words, computers should use UT1 (where one day is a rotation of the earth, and 86400 seconds; and consequently a second is not a SI second).

Re: Falsehoods programmers believe about Unix time

#155

Post by tus87 »

AgentME wrote: post #140
tus87 wrote: post #76

Earlier quoted context omitted.

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

Yes.

Re: Falsehoods programmers believe about Unix time

#156

Post by FabHK »

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…

If what you said were true, then UNIX time were at some fixed offset to TAI. But it's not.

Re: Falsehoods programmers believe about Unix time

#157

Post by msla »

FabHK wrote: post #144
msla wrote: post #77

Earlier quoted context omitted.

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

My point is this: Most people don't know about UTC/TAI/UT1 or any other standard. They know what's common knowledge, and what's common knowledge is that one day is 24 hours precisely, one hour is sixty minutes precisely, and one minute is sixty seconds precisely. Therefore, when writing software to interface with most people, including businesses with contracts defined in terms of those time definitions, one day is 24 hours or else you end up with problems.

Re: Falsehoods programmers believe about Unix time

#158

Post by btilly »

GordonS wrote: post #142
btilly wrote: post #138

Earlier quoted context omitted.

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.

What it means is that the discrepancy between clocks and time of day is growing quadratically. It won't matter to us in our lifetimes. But eventually it will be a problem.

It will take on the order of a thousand years for the discrepancy to add up to an hour. In 5000 years, it will be around a day. The fact that it is currently growing about a minute per century is true, but not a good predictor of what will happen.

That said, I prefer if we just lose the astronomical basis for time keeping, and let our distant descendants figure out that they should use time zones, and not modify UTC. Hopefully by the time it becomes obvious that clocks are drifting too fast for time zones to change all of the time, we're a multi-planetary species and paying attention to what is happening on the Earth seems quaint.

Re: Falsehoods programmers believe about Unix time

#159

Post by JdeBP »

A falsehood that Alex Chan believes about UNIX:

No-one uses the Olson "right" TZ data files.

What is stated in M. Chan's article is only true when using the "posix" TZ data files. But that's not the only option.

* https://unix.stackexchange.com/a/327403/5132

* https://unix.stackexchange.com/a/334029/5132

* https://unix.stackexchange.com/a/294715/5132

Re: Falsehoods programmers believe about Unix time

#160

Post by taneq »

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 third principle is about facing (and implicitly, automating) your difficult-but-necessary processes. Outside of that narrow scope it's terrible advice. Being in a car crash and converting a country from one system of units to another are both difficult and painful and you should do either as seldom as possible.
Post reply on HN