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

261–270 of 275 posts

Re: Falsehoods programmers believe about Unix time

#261

Post by insulanus »

xmprt wrote: post #99
throw0101a wrote: post #52

Earlier quoted context omitted.

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.

Leap years have pretty straightforward rules for when they happens. Approximately every 4 years, expect on 100 years, except on 400 years. Leap seconds on the other hand happen at the whim of the IERS

A nice hack for a time system for Earth might be to add the leap seconds on the last day of leap years.

That would keep the time and date adjustment code together in one place.

Re: Falsehoods programmers believe about Unix time

#262

Post by bheiskell »

rlucas wrote: post #260

My Unix time question is, when I do “sudo date ” and then get a sudo password prompt, is the time supposed to take effect before or after the sudo is authenticated? Emprically it seems to be after but that seems wrong; shouldn’t the result of the command be the same regardless of how long it takes to type the sudoer’s pw?

After, because sudo won’t run any command until it authorizes that you’re allowed to run the command.

Re: Falsehoods programmers believe about Unix time

#263

Post by lozf »

jondubois wrote: post #218
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…

We should abolish local time too. There should be a single time for every country which is the number of milliseconds since either the beginning of human civilization, the beginning of earth or the universe.

Mean Julian Days (MJD) are the agreed standard for something like that. Abolishing local time has a number of issues as linked in other comments. The time standards we currently have are all well suited to their purpose, it's just a case of picking the most appropriate one for the task. (Plenty of room for more TAI in modern technology).

Re: Falsehoods programmers believe about Unix time

#264

Post by twic »

InitialLastName wrote: post #150
twic wrote: post #133

Earlier quoted context omitted.

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.

Nope. Is sunset when the lower limb of the sun touches the horizon? When it's halfway? When it disappears completely? And is that the actual horizon where the sun happens to be today? The treeline above it? The tower block in the way? Where sea level would be if there wasn't land there? Or just when it gets dark? But then is that civil twilight? Nautical twilight? Astronomical twilight? When the light from the sun gets dimmer than the light from the streetlights that happen to be in your area?

Re: Falsehoods programmers believe about Unix time

#265

Post by tinus_hn »

wmf wrote: post #130
lutorm wrote: post #97

Earlier quoted context omitted.

It's a lot easier to test and prepare for something that occurs at least semi-regularly than a monumental event far into the future that is "so far into the future we don't have to worry about it"....

If we abolish leap seconds (and any other changes to UTC) and let the error accumulate until it hits 30 minutes then a 1-hour time zone change can adjust for it. Time zone changes happen at least semi-regularly so it wouldn't be monumental.

It would take millennia for such an error to accumulate. Leap seconds are inserted less than once a year and 30 minutes is 1800 seconds.

Re: Falsehoods programmers believe about Unix time

#266

Post by AgentME »

masklinn wrote: post #227
AgentME wrote: post #136

Earlier quoted context omitted.

I think that's a better way of putting it. The main lesson is that there's no operation called "changing the timezone of a Unix timestamp", and any code trying to do that is wrong. A date string is a function of a Unix timestamp and a timezone, and if you need to change the timezone, you need to pass a different timezone parameter, not try to do something to the Unix timestamp part.

> A date string is a function of a Unix timestamp and a timezone If offset or zoned. Sadly the average date string has no more inherent timezone information than a unix timestamp.

I meant that a datetime string is generated from the combination of a Unix timestamp and a timezone together, not that it lossily retains both of those inputs. For example, if I want to show the time of day of an event like "3:12 AM" to the user, then I need both the Unix timestamp of the event (for example, 1558050450579) and their timezone (could be as a UTC offset, like -7) in order to produce "4:47 PM". That's true whenever I'm trying to make a string from a Unix timestamp, regardless of whether the final date/time string explicitly says its timezone.

Re: Falsehoods programmers believe about Unix time

#267

Post by bloak »

tinus_hn wrote: post #265
wmf wrote: post #130

Earlier quoted context omitted.

If we abolish leap seconds (and any other changes to UTC) and let the error accumulate until it hits 30 minutes then a 1-hour time zone change can adjust for it. Time zone changes happen at least semi-regularly so it wouldn't be monumental.

It would take millennia for such an error to accumulate. Leap seconds are inserted less than once a year and 30 minutes is 1800 seconds.

Falsehoods programmers believe about leap seconds: 1. The rate at which leap seconds are inserted will remain roughly constant. [...]

The Earth's rotation is slowing down (by about 2 ms per day per century), so the difference between TAI and UT1 is increasing quadratically, not linearly.

Re: Falsehoods programmers believe about Unix time

#268

Post by FabHK »

someguydave wrote: post #181
FabHK wrote: post #152

Earlier quoted context omitted.

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

People who want a predictable and monotonic time scale

SI seconds (in UTC) lead to leap seconds. With UT1, "1/86400 of a day" seconds lead to a predictable and monotonic time scale.

Re: Falsehoods programmers believe about Unix time

#269

Post by FabHK »

msla wrote: post #157
FabHK wrote: post #144

Earlier quoted context omitted.

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

That's why I advocate using UT1 in programming (like Julia), where all of the above is true. The cost we pay for that is that a UT1 second is not exactly a SI second, but I don't see how that matters except in GPS etc.

Re: Falsehoods programmers believe about Unix time

#270

Post by bcaa7f3a8bbc »

wodenokoto wrote: post #224
bcaa7f3a8bbc wrote: post #177

The original purpose of Unix time was decoupling local time representation and internal timekeeping of the system. Unix time could be the "One True Time" of the system, it always increases monotonically. When you need local time, all the tricky and nasty details, including DST, mandated calendar changes, etc, are processed by the tzinfo system library/database. If the calendar has changed, at least in principle one d…

Obviously, given the article and the discussion I am wrong, but what you propose sounds to me exactly like the definition of unix time: The number of seconds since January 1. 1970 UTC. Even if UTC counts the same second twice, this does not change how many seconds has elapsed since the unix epoch. If you click through the articles reference to wikipedia and again from there, you will end up on "The Open Group Base Sp…

Thanks for the interesting link, good to know! So we are in fact, pretty close to a monotonically-increasing, TAI-like Unix clock.

The original article said,

> Each Unix day has the same number of seconds, so it can’t just add an extra second – instead, it repeats the Unix timestamps for the last second of the day.

Your POSIX link says,

> As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.

I'm not a expert on timekeeping, but it appears the only problem here is that the Unix time is bounded by a 86,400-second day, which I guess was meant to make a Unix day predictable, so we still have to double count or skip seconds. It seems the only thing we need to make Unix time monotonic is simply removing the 86,400 seconds Unix day from specification.

On the other hand, it means a Unix day would be unpredictable and it would be impossible to calculate a Unix time without a database, and difficult calculate future Unix time using calendar time. So TAI doesn't automatically solve every problem, everything comes with a tradeoff.

But I think a unpredictable Unix day should be fine for purpose of an internal system clock, so perhaps it's still not a bad idea.

Post reply on HN