Falsehoods programmers believe about Unix time • Hacker News Board

Re: Falsehoods programmers believe about Unix time

#201

Post by astrange » Thu, May 16, 2019, 3:32 AM UTC

cat199 wrote: post #129

yanowitz wrote: post #28

chrony[1] neatly solves these and a host of related issues by guaranteeing time increases monotonically on a given host, speeding up or slowing down the clock appropriately. It's a nicer alternative to ntpd. Also, AWS recommends it if you are using their Time Sync service (which is GPS-locked atomic clocks in every region with leap second smearing). [1]

> It's a nicer alternative to ntpd. define nicer?

ntpd is a pretty weird daemon in the same way that bind is. The config format is insecure and impossible to understand; if you try to change it you'll probably break it.

Re: Falsehoods programmers believe about Unix time

#202

Post by nine_k » Thu, May 16, 2019, 3:35 AM UTC

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…

1 minute of drift seems fine. 1 hour of drift is rather noticeable.

If the drift is about 0.5 second per year, about a minute of drift will have to be compensated on a century border.

Re: Falsehoods programmers believe about Unix time

#203

Post by wmf » Thu, May 16, 2019, 4:29 AM UTC

quickthrower2 wrote: post #197

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.

Wouldn’t that move the international date line?

I guess so, but I don't know why that matters.

Re: Falsehoods programmers believe about Unix time

#204

Post by brianpan » Thu, May 16, 2019, 4:51 AM UTC

max76 wrote: post #192

I think we should have a scientific definition of time -- something that is highly static and precise (such as the time it takes for an atom to vibrant a number of times, or the time it takes light in a vacuum to travel a certain distance) and a cultural definition of time that is more loose than UTC (There is always the same number of seconds in a day, but maybe some days have shorter seconds than other days). Cultu…

Time might not be too hard to define (relativistic effects aside), but the problem is days and years. The reason for inserting and removing seconds is because the rotation of the earth is NOT static and precise. It changes so seconds are added and removed to keep the day from drifting.

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

Re: Falsehoods programmers believe about Unix time

#205

Post by not_kurt_godel » Thu, May 16, 2019, 5:04 AM UTC

taneq wrote: post #171

macspoofing wrote: post #166

Earlier quoted context omitted.

That's not anywhere close to "the best solution"

This discussion isn't going to be very meaningful unless you wanna tell us what 'best' means to you.

Are we to infer that your lack of criteria for "best" in your own post means that it too is meaningless? You made a breath-taking leap going from {our society isn't as dependent on planting and harvesting anymore} to {therefore it's "probably best" to radically alter universal concepts of temporality to partially solve an obscure technical problem}. Methinks the burden on proof lies firmly in your court on this one.

Re: Falsehoods programmers believe about Unix time

#206

Post by lifthrasiir » Thu, May 16, 2019, 5:05 AM UTC

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…

Technically speaking double negative leap seconds will break the monotonicity of time_t as well. Fortunately for us, there is no provision of double (positive or negative) leap seconds [1]; ISO C's range for tm_sec, which allows for 61, was a mistake [1; "not really UTC in 1989/1990" section].

[1] https://www.ucolick.org/~sla/leapsecs/timescales.html#UTC

Re: Falsehoods programmers believe about Unix time

#207

Post by mikorym » Thu, May 16, 2019, 5:19 AM UTC

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…

> The idea that I don't know how many UTC seconds will pass between now and May 15, 2022 0:00:00 is absurd.

Why don't you use TAI then for this purpose?

I think the notion of time in relation to the earth's movements (for timekeeping on earth) is fair.

Re: Falsehoods programmers believe about Unix time

#208

Post by dancek » Thu, May 16, 2019, 5:42 AM UTC

I've been thinking about datetime APIs and how most of them become extremely tedious when you have to account for daylight saving, countries changing time zones et cetera. I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing. But then I considered leap seconds.

I don't know if there are libraries that can handle leap seconds or is everyone just counting on NTP sync fixing things whenever a leap second occurs.

Re: Falsehoods programmers believe about Unix time

#209

Post by nicky0 » Thu, May 16, 2019, 5:50 AM UTC

taneq wrote: post #161

indigo945 wrote: post #145

Earlier quoted context omitted.

The obvious correction is to change the duration of a second such that a year is exactly $integer seconds long. While this will make the duration of second drift from year to year, that drift is so small that everyday devices like consumer-grade computers could just ignore it, provided they're NTP synced once every five years or so. Physicists can just keep using whatever they're using and call it by a different name…

The core issue is that the number of days per year is messy, so it's not possible to have a 'nice' number of seconds in a day and also in a year. The best solution is probably just to use a nice number of seconds per day and accept the fact that in 100ish years summer will start in March, not December. It's not like we need to build our entire society around planting and harvest any more.

But we do build our entire society around sports seasons.

Re: Falsehoods programmers believe about Unix time

#210

Post by taneq » Thu, May 16, 2019, 5:57 AM UTC

not_kurt_godel wrote: post #205

taneq wrote: post #171

Earlier quoted context omitted.

This discussion isn't going to be very meaningful unless you wanna tell us what 'best' means to you.

Are we to infer that your lack of criteria for "best" in your own post means that it too is meaningless? You made a breath-taking leap going from {our society isn't as dependent on planting and harvesting anymore} to {therefore it's "probably best" to radically alter universal concepts of temporality to partially solve an obscure technical problem}. Methinks the burden on proof lies firmly in your court on this one.

I'm not the one arguing with a statement in that post.