What causes changes in the rate of rotation of the earth?
China slowed the rotation of the earth very slightly when they built the Three Gorges Dam.
https://www.kinetica.co.uk/2014/03/27/chinese-dam-slows-down...
Leap second hiatus
101–110 of 117 posts
Re: Leap second hiatus
#102Earlier quoted context omitted.
How does TAI relate to Epoch time? More and more I use Epoch time for most things just because of how convenient it is. I rarely need sub-second granularity, and it's just one number, so it's sortable, math-able, etc. Then whoever is doing the display can convert it any way they want to.
Remember that your code needs to account for the possibility of a negative leap second, meaning if you're using epoch time for timestamps you could have an instance that an event that happened after a previous one could be stamped as having happened before it instead. https://en.wikipedia.org/wiki/Leap_second Edit: Actually I was slightly wrong, in the event of a leap second, we would repeat the same second twice.
Thank you for the heads-up!
I try to write code loose enough that this would not be a problem. :)
Re: Leap second hiatus
#103Earlier quoted context omitted.
Pretty much all telescopes (under computer/time control) on this planet rely on UTC being quite close to UT1, since every second difference leads to a 15 arcsecond error in the pointing of the telescope (error between where you want to point the telescope on the sky and where you are actually pointing). While <5s is usually not a problem (except for some instruments with very very small FoV), at 30s it really becomes…
I would think this is an argument for telescopes using UT1, not whether UTC should be adjusted for leap seconds. This is such a fringe application and all involved are aware of the issue, that I don't think it's relevant here at all.
UTC is defined to be within 1s of mean solar time at 0deg longitude (= UT1).
If leap seconds are a problem for the intended application then UTC is the wrong thing to use. There are other scales that are defined differently that can be used in it's place (such as TAI).
However if exact frequency is not critical one could also directly use UT1 instead of UTC (people that use leap second smearing for instance should have no issue with that..).
Re: Leap second hiatus
#104Many computer programs use UTC time (which means you have to deal with leap seconds) when they really should be using TAI (which is based purely on the physical progression of time on the earth's geoid, with no arbitrary input that has to be updated periodically). https://cr.yp.to/proto/utctai.html Generally, you should only be dealing with UTC for things that have to display/accept a time to/from human users; there'…
I hear this argument quite a lot. But using TAI is no different from using UTC in terms of complexity because both requires the complex problem of data distribution (either of leap seconds or of UTC-TAI differences). If you ever have to use UTC somewhere you can't escape from that problem; using TAI is only moving the goalpost.
Using TAI is simpler because:
* Many apps can get away with only using TAI, so they don't necessarily have to track the difference between UTC and TAI
* If your system uses TAI in its distributed coordination mechanisms, you don't need to worry about leap seconds and an error in the UTC-TAI difference won't cause your system to fail
Re: Leap second hiatus
#105Earlier quoted context omitted.
I hear this argument quite a lot. But using TAI is no different from using UTC in terms of complexity because both requires the complex problem of data distribution (either of leap seconds or of UTC-TAI differences). If you ever have to use UTC somewhere you can't escape from that problem; using TAI is only moving the goalpost.
Using TAI is simpler because: * Many apps can get away with only using TAI, so they don't necessarily have to track the difference between UTC and TAI * If your system uses TAI in its distributed coordination mechanisms, you don't need to worry about leap seconds and an error in the UTC-TAI difference won't cause your system to fail
> Many apps can get away with only using TAI, so they don't necessarily have to track the difference between UTC and TAI
Most systems don't need to keep the difference between UTC and TAI to display the UTC time anyway. TAI matters when you have to manipulate the non-zoned wall clock (as opposed to date and time components) and that's surprisingly rare.
> If your system uses TAI in its distributed coordination mechanisms, you don't need to worry about leap seconds and an error in the UTC-TAI difference won't cause your system to fail
This is a legitimate concern, but TAI is not the solution (you should probably be using PTP or GPS clock if you do care that much) nor an essential part of the solution (any monotonic clock, including "leap smears" and UTC-SLS, will do fine). In fact I think most perceived benefits of TAI are actually of monotonic clocks and not inherent to TAI, and UTC is already monotonic... (Yes, I'm distinguishing the actual UTC and time_t; for the latter there is a relatively simple conversion to monotonic however.)
Re: Leap second hiatus
#106Earlier quoted context omitted.
Sure, we will randomly move the end of the DST from the last Sunday of October to the first Sunday of November and everyone will try to kill us, right? DST is the perfect example that we have a relative freedom in changing time zone offsets. You are however right that this is a political matter requiring some (but I believe, reasonable) amount of coordination, but timekeeping is in many parts political anyway. Practi…
> we have a relative freedom in changing time zone offsets Who is we in this sentence? Programmers certainly don't, they have to report times and timezones in their software as the populace expects it to be reported. Governments can change timezones, but they're not going to, because the political cost of telling everyone that they're in a new timezone is greater than the political cost of telling programmers where t…
Russia decided to just stay on DST with 6 weeks notice a few years ago, thereby instantly creating half a dozen new timezones. And now they're discussing going back to normal time/DST...
Re: Leap second hiatus
#107Earlier quoted context omitted.
People who can't cope with leap seconds should stop pestering the people who define UTC and just switch to TAI. They can do that now. No one is stopping them. Leap seconds are a pain and I myself would happily choose TAI over UTC for the system clock on a typical embedded system. However, for civil time keeping and for some technical purposes, UTC as currently defined is exactly what we need. Don't fuck with it.
No, they can't. Programmers have to deal with the outside world. The outside world has timezones defined as offsets from UTC. So when UTC changes, the whole world changes their clocks, and programmers have to cope. If your program doesn't agree with that world about what time it is, your program will get blamed. If it was a choice that I could individually make, I would tell astronomers to go pound sand. But it isn't…
Why not derive UTC from TAI (via a table of leap seconds)? Then apply the TZ rules to DST to arrive at local time.
Re: Leap second hiatus
#108What causes changes in the rate of rotation of the earth?
The angular momentum of the "earth system" is constant [1]. The variation in angular velocity of the solid earth can be ascribed to change in the angular momentum carried by oceans and atmosphere. These changes can be due to change in velocity (winds, currents) or moment of inertia (moisture in atmosphere). [1] If we ignore friction due to tidal forces from moon and sun (which is valid on these time-scales), the "ear…
Slowing down of the earth is caused by wind turbines, just as extracting energy from the tides causes the moon to fall towards the earth. When the earth will have completely stopped rotating, and the moon be dangerous close to the earth, that will be yet another shitshow. And they call this "renewable energy"?
P.S.: not serious
Re: Leap second hiatus
#109Earlier quoted context omitted.
No, they can't. Programmers have to deal with the outside world. The outside world has timezones defined as offsets from UTC. So when UTC changes, the whole world changes their clocks, and programmers have to cope. If your program doesn't agree with that world about what time it is, your program will get blamed. If it was a choice that I could individually make, I would tell astronomers to go pound sand. But it isn't…
Why not derive UTC from TAI (via a table of leap seconds)? Then apply the TZ rules to DST to arrive at local time.
The short answer is that I don't do this because I'm not insane.
Think about it. How much software would I have to rewrite to make this possible? What value does that rewrite create? And will maintenance programmers thank me for it? Will it get adopted?
As a programmer I have to interact with databases, operating systems, various libraries in various languages, and so on. Frequently with quick switching between them. ALL are written assuming UTC. Shall I name myself Don Quixote and spend the rest of my life on a rewrite that nobody wants to us?
Just to give a sense, I recently had to do some data science tasks. Data was in Postgres, my code was in Python, using pandas for speed, and pandas is built on numpy. All four of those have their own datetime library, and I had to deal with all four of them. If I followed your suggestion, before I did any work I'd have to rewrite all 4 libraries, and then figure out how to replace Amazon RDS because it doesn't support my "improved Postgres".
And if I did all of that, I've not changed the odds of something like https://www.wired.com/2012/07/leap-second-glitch-explained/ happening again and taking down my favorite websites for a while. Because guess what, they won't be running my super-duper rewritten code.
Re: Leap second hiatus
#110Earlier quoted context omitted.
>'From the perspective of the typical time_t rendering of Unix time, there is no way to uniquely represent that 61st second. It just "disappears".' This is a great and really intuitive summary of the problem. Is there a certain class of problem related to disappearing second? Like are these more likely to be filesystem issues or things that rely on timestamps? Or are there second order problems as well? >"I can tell…
Well, okay, so, the problem is like this: let's say you wanted to schedule something to happen during that exact extra second in the end of June 2015 when we were all standing around watching UTC do its little extra dance. You pick 1435708800. Trouble is, that Unix time applies to both 23:59:59Z and 23:59:60Z on that particular day. You can't target it beforehand or after. It's just... gone. It's not a problem from t…
Great explanations. Thanks!