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

41–50 of 275 posts

Re: Falsehoods programmers believe about Unix time

#41

Post by m1el »

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…

> 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 now measure time with precision high enough that tying to Earth's rotation is not acceptable. We can still use timezones to fix the shift.

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

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?

Re: Falsehoods programmers believe about Unix time

#42

Post by jhayward »

One thing that this article evokes is the 'I'm wrong and my belief is deeply held' aspect which technology people occasionally fall in to. Looking at the comments, with incorrect beliefs expressed as dicta ranging from just plain wrong, to incompletely specified, to ordinary confusion is giving my tech-PTSD a workout.

There are topics in which the ordinary or common sense understanding of a thing actually interferes in understanding how that topic actually acts in reality when looked at closely or under complex conditions.

The concept of time is one of those things. The best thing a naive developer can do when reasoning about time is to first know that almost everything they assume is wrong, and they don't even know what their assumptions are.

The concept of 'location' is another of these topics.

I would like to close this comment with a helpful link to a concise introduction for people to start with in clearing out the 'common sense' assumptions but I haven't ever found one, and haven't invested enough time to write one. Sorry. Links to same will be gratefully received.

Re: Falsehoods programmers believe about Unix time

#43

Post by chessturk »

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…

A friend of mine was getting a real estate license and talked to me about the insane ways land ownership is measured, because the curvature of the earth. I believe that was just the tip of the iceburg. I'll have to check out geodesy.

I remember an ancient mathmatician described how all of existence must be a single geometric point, I think it was Euclid, but I can't find it. This all reminds me of that.

Re: Falsehoods programmers believe about Unix time

#44

Post by speleo_engr »

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…

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 minute of drift, or 1 hour of drift? We are putting out problematic corrections for something a minor drift on the scale of years that should be happening on the scale of centuries or millennia in my opinion.

Re: Falsehoods programmers believe about Unix time

#45

Post by jhayward »

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…

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.

Re: Falsehoods programmers believe about Unix time

#46

Post by AgentME »

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 receives a Unix timestamp from your server, you shouldn't modify the Unix timestamp to "convert" it to your user's local timezone. Unix timestamps are always UTC. Your platform's date handling APIs should already offer a way to display a Unix timestamp in the user's timezone or an arbitrary one, and maybe even have a class that represents a Unix timestamp paired up with a specific timezone. At no point should you be doing arithmetic on the Unix timestamp portion to convert it between timezones.

Re: Falsehoods programmers believe about Unix time

#47

Post by fallous »

Verdex wrote: post #32
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). Add…

Yes, the use-case and domain set the constraints. Using the wrong measurement type or abstraction either increases the complexity of the exceptions necessary to make it fit the constraints or increases the inaccuracy/errors... or both.

With regards to time specifically, I recall many years ago talking with an economics professor I had that was from Zimbabwe and he mentioned the frustration that western industrial nations had when attempting to establish business in Africa. Industrial nations long ago became dependent upon a higher resolution and accuracy of time and so when they say "2PM" they expect accuracy within a minute or two. But the African work force would often show up at 3PM and when confronted by this "lateness" they would reply "3 is the friend of 2." An agrarian or pre-industrial society has no real need for accuracy to the minute, but instead can operate quite well with human observation of the position of the sun. This impedance mismatch caused no end of frustration on both sides, since neither could really fully understand the other's conception of timeliness.

Re: Falsehoods programmers believe about Unix time

#48

Post by aflag »

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…

Are you saying Unix time doesn't get adjusted when there are calendar changes in the box?

Re: Falsehoods programmers believe about Unix time

#49

Post by toast0 »

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…

POSIX defines gettimeofday [1], which fills a timeval with integer (time_t) seconds and integer (suseconds_t) microseconds.

Is your concern over weather Unix Time is a time_t or a timeval?

A time_t shouldn't go backwards (in normal operation), but a timeval does.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...

Re: Falsehoods programmers believe about Unix time

#50

Post by Florin_Andrei »

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…

> Here's a falsehood I've seen a bunch of times: the idea that Unix timestamps need to be converted to your local timezone.

That's less of a "falsehood", more of a complete misunderstanding of what Unix time is.

Post reply on HN