Never knew about this... interesting article!
Falsehoods programmers believe about Unix time
121–130 of 275 posts
Re: Falsehoods programmers believe about Unix time
#122Earlier quoted context omitted.
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
I've spent a lot of time finding objects in the sky to high accuracy with astronomical algorithms. The first step is always converting from UTC to TAI. See Astronomical Algorithms by Jean Meeus if you don't believe me. Your noon example works for a single longitude in a time zone and the time between subsequent noons on two different days will only be exactly 24 hours 4 times a year. It seems unnecessarily complex to…
> The first step is always converting from UTC to TAI
I believe you are actually converting to Terrestrial Time. If there is a correction of TAI+32.184 seconds in your calculation, that would indicate TT.
Re: Falsehoods programmers believe about Unix time
#123Earlier 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.
> 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.
That is what a lot of organizations do, "smearing" the leap second since they know their systems can't handle the discontinuity. I think this shows that software has failed in general at handling leap seconds correctly. As another said, I think leap seconds are unnecessary complexity with the frequency at which they happen.
Re: Falsehoods programmers believe about Unix time
#124Earlier quoted context omitted.
I've spent a lot of time finding objects in the sky to high accuracy with astronomical algorithms. The first step is always converting from UTC to TAI. See Astronomical Algorithms by Jean Meeus if you don't believe me. Your noon example works for a single longitude in a time zone and the time between subsequent noons on two different days will only be exactly 24 hours 4 times a year. It seems unnecessarily complex to…
> The first step is always converting from UTC to TAI I believe you are actually converting to Terrestrial Time. If there is a correction of TAI+32.184 seconds in your calculation, that would indicate TT.
Yes, it is ultimately TT. The order goes:
UTC -> TAI -> TT
I could argue the TAI to TT is the second step. But let's put the pedantry aside: Is your best answer of something made easier in the modern world by leap seconds ensuring that solar noon happens at exactly 12:00:00 four times a year on an exact line of longitude for the time zone? And 4 times a year would require a time zone that does not honor daylight time, otherwise it is twice.
I'm not some crackpot here talking about the absurdity of leap seconds. US, China, Australia, Japan, S. Korea are on board for discussions about abolishing to happen in 2023.
Re: Falsehoods programmers believe about Unix time
#125I 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.
It's perfectly sensible though? 0:00:00 is a designation of an event. Namely, the event of midnight during a particular rotation of our planet. Every calendar day is one rotation, so May 15, 2022 is also an event -- it's that many rotations of Earth after today. But a second is a duration and it's independent of Earth's rotation. An asteroid could hit the earth and make the rotation shorter or longer (or just shatter the planet...) in the meantime. You obviously can't know how many seconds will pass until that particular midnight. It's inconvenient, but it makes perfect sense when you can't predict the future.
Re: Falsehoods programmers believe about Unix time
#126I 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…
There have been a net +27 leap seconds since the 1970’s. That’s not enough to turn summer into winter or day into night. That’s roughly a full minute per century.
Re: Falsehoods programmers believe about Unix time
#127Earlier quoted context omitted.
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!
Happy to see it is not just me that enjoy getting rid of my ignorance : )
Re: Falsehoods programmers believe about Unix time
#128Earlier quoted context omitted.
Some probing questions: Alice and Bob both live in England and have planned a conference call at 15:00 on 4-jan. Now Alice happens to travel, and she is in American on 4-jan. What should here calendar do? Moreover, Alice also has a recurring event "Workout" every friday at 9:00, what should that shift to? Finally, it turns out Bob is also in America, what time should the conference call be at now? Finally, for some r…
In your case, you're not doing the specific thing I prohibited. I only meant you should never do arithmetic on a timestamp to try to "convert" it to an equivalent representation of the same instant (as Java 8 defines it) in another timezone. However you're specifically doing arithmetic on the timestamp to calculate a new different instant, which is fine. (Your case isn't that different than the user pressing a "shift…
> you should only store timestamps of past events and events that happen at a fixed instant regardless of calendars and wall clocks as Unix timestamps
I think this works more often than not, but it's hardly foolproof or without repercussions. Say, you can imagine Google Calendar having a list of holidays for the US. Say it's New Year's day. You're saying you'd replicate that into 6 epoch timestamps (one per time zone in the US) per year in the past, instead of just storing it as "January 1, 00:00:00, recurring every year"?
Re: Falsehoods programmers believe about Unix time
#129chrony[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?
Re: Falsehoods programmers believe about Unix time
#130Earlier quoted context omitted.
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…
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.