13 ms·
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 importan
by speleo_engr 7y ago
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 programmatically. People think time increases monotonically and it's confusing to push it any other way.
The idea that I don't know how many UTC seconds will pass between now and May 15, 2022 0:00:00 is absurd. The fact that a clock sometimes reads 23:59:60 is also absurd, as is the "possibility" of a 23:59:59 being a forbidden time on a certain date if we ever add a leap second of the opposite sign.
- jordanpg 7y agoThis made me think of time in science fiction, eg. https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste.... On a long enough horizon, I take it as a foregone conclusion that simple metric measurements will become standard.
- labster 7y agoLeap seconds are useful if you're an astronomer. Astronomers have always determined the current time. Therefore, we all get leap seconds.
- planteen 7y agoHow are leap seconds useful if you are an astronomer? I am genuinely curious what problem in the year 2019 is easier due to leap seconds. I have worked on code that needed to do astronomical calculations to do things like: position of sun, moon, Mars, Earth, and spacecraft ECI <-> ECEF All of these depend on a conversion from UTC to TAI. It's covered in books like Astronomical Algorithms in the intro: https://www.willbell.com/math/MC1.HTM https://www.willbell.com/math/MC1.HTM
- someguydave 7y agoThe only one I can think of is: determining the phase of the 24 hour day (as measured by atomic clocks) with respect to the Earth's rotation. It does seem logical use TAI for civil time. People interested in calculating the Earth's rotation to high precision could consult a regularly-updated publication somewhere. Eventually the Earth's rotation will drift out-of-sync with the atomic clock timebase, but that won't be important until we accumulate several minutes/hours of error from TAI which could be centuries from now.
- FabHK 7y agoWhy TAI and not UT1? Who/what really cares about SI seconds?
- someguydave 7y agoPeople who want a predictable and monotonic time scale
- FabHK 7y agoSI seconds (in UTC) lead to leap seconds. With UT1, "1/86400 of a day" seconds lead to a predictable and monotonic time scale.
- someguydave 7y agoUnfortunately, electronic devices come with quartz crystal resonators, or rubidium or cesium resonators. After frequency calibration these will keep stable time relative to the atomic clock timebase. There is no device available that allow you to derive a clock from the relative motion of the sun about the Earth’s axis, such that the changing definition of days and seconds relative to realizable clocks can be tracked. Furthermore it’s kind of nice to have a stable and standard definition of seconds and days. For instance, under the “ut1 system” you don’t know how long a present second is until the present day’s final observations are made.
- jhayward 7y ago> 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 fascinating ways, you should fall down the geodesy hole some time. Saying 'where' on earth something is located is .. not simple.
- ergothus 7y ago> 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 obstinate - it's just that without examples your response boils down to "No it's not" without further support. I'm open to being convinced...convince me.
- jhayward 7y agoWe 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.
- ergothus 7y agoAnd the leap seconds meaningfully alter that?
- lutorm 7y agoYes. Leap seconds are there to align UTC (an atomic time) with UT1, which is defined based on mean solar time, ie "the day", since UT1 isn't uniform. Without leap seconds, UTC will slowly drift out of sync with the Earth's rotation.
- Verdex 7y agoI 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). Additionally, if you have something which is easy to understand that is fed into multiple incompatible things (either the things are easy to understand or hard to understand), then the whole system becomes harder to understand. Finally, if the starting point that is fed into all other things is not actually easy to understand but in fact hard to understand ... things can get pretty bad. Even if time was easy to understand by itself, then I still think it would be pretty hard to deal with because it is used for multiple incompatible domains (astronomical vs how long a day is on earth for example).
- fallous 7y agoYes, 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.
- endymi0n 7y agoWell, 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 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 is a hard cultural and religious boundary for just about everything in life. A month is roughly the rotation of the moon around the earth (although that definition is arguably the weakest and ready to go) A year is defined as the rotation of the earth around the sun. Changing any of these will make the summer drift into the winter, or the night into the day, or whatever. Time just isn't simple, and although most of these intervals _almost_ fit within each other, reality is that they don't and we'll always have artifacts. If you enjoy philosophy on these kinds of imperfections as much as I do, I can heavily recommend this article about musical tuning: https://blogs.scientificamerican.com/roots-of-unity/the-saddest-thing-i-know-about-the-integers/ https://blogs.scientificamerican.com/roots-of-unity/the-sadd...
- m1el 7y ago> 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 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?
- endymi0n 7y ago> 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? No, I don't, as they are just views on a monotonically increasing time scale named UTC that keeps up with Earth's rotation, so that every single thing from climate diagrams to everything else humanity is syncing on keeps working and being comparable. > We can still use timezones to fix the shift. Or, we could not do that. Everyone is free to use TAI inside their own projects as they see fit if they have the needs for strictly monotonically increasing time. I would argue that leap second smearing has way less artifacts in practice than bolting time zones onto a shifting UTC time.
- throw0101a 7y agoSome 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.
- xmprt 7y agoLeap 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
- scythe 7y agoLeap years are actually just slightly inaccurate. Leap years estimate an orbital period of 364.2425 days but the actual orbital period is 365.24217 days. Also, it should be noted that basically nobody actually understands a "year" to mean an orbit of Earth around the Sun relative to the Local Standard of Rest, which is called a sidereal year (ca. 365.256 days). Instead, to most people, a year means a cycle of seasons which recreates the same angle between the Earth-Sun axis and the Earth's axial tilt, which generates seasonal temperatures and is called a tropical year. Because the axial tilt is variable, the tropical year also varies and eventually drifts away from the sidereal year. The tropical year and sidereal year differ by about 20 minutes, so today's year starts about a month "away" from the year Julius Caesar enacted the first true solar calendar. The difficulty in this case is that spinning rocks in space can float around however they please.
- insulanus 7y agoA 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.
- KayEss 7y ago> Some people think that a day is one revolution of Earth's axis, and not exactly 86400 seconds One day is more than one revolution of the planet. The sidereal day is exactly one rotation of the planet, but that's about four minutes shorter than a civil day. The reason is that the planet also moves around the sun, so in order to get the sun to the same position in the sky for noon the planet needs to turn a little bit more than 360 degrees, about 360/365 extra.
- petschge 7y agoUsually the first step is to correct from what ever the local clock at the observatory said to actual UTC. Then you convert from UTC to TAI. And then you convert from TAI to the arrival time at the solar barycenter, removing the geometric light travel time to Earth (or more precisely the observatory) as well as the gravitational effects of Sun, Jupiter and Earth.
- skybrian 7y agoFor most practical purposes (like knowing when to show up at a meeting), you need to know local time. Even if you got rid of leap seconds, you still wouldn't know for sure how many seconds there are between now and some date and time in 2022 because you don't know what the local timezone will do. It's not clear why this is a useful calculation? For scheduling events in the future, you need to store the timezone (or location) and local time anyway. Unix time is a useful approximation for comparing and converting between local times.
- maxnoe 7y agoAstronomy has the need for both. A notion of an instant in time that advances linearly without any ambiguities, which would be TAI, and a notion of the precise orientation of Earth, which would be UTC. To record events, you will use TAI, to point your telescope to a celestial object, you will use UTC.
- lutorm 7y agoAstronomers don't really use UTC for pointing telescopes though, they use sidereal time. A sidereal day is 4 minutes different from a mean solar (UTC) day, so you still have to do a conversion. You still need something that keeps track of the Earth's rotation, but presumably the ITU will still keep track of the difference between UT1 and UTC. I'm an (ex-) astrophysicist, but I'm not convinced that astronomy would actually be particularly impacted if leap seconds would stop being applied to UTC. You already need to keep a leap second table, it would just shift where you apply it.
- mikedilger 7y agoI don't mind having UTC with leap seconds, but I do mind it being the defacto standard. NTP would be more useful if it was synchronizing TAI.
- mavhc 7y agoStoring computer time as something related to UTC is flawed, should use TAI. Solves the leap second problem, you're already converting time to display it to humans, and for time zones, so correcting for leap seconds is just one more step.
- mehrdadn 7y ago> 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.
- tux1968 7y ago> Move any jumps in time to once a century (or millennium). You hear a lot of people remarking that Let's Encrypt has made things better by requiring certs to be reconfigured more often rather than less. I know they're not exactly the same as time in general, but as a general idea, knowing that you need to do some fiddling often and automating it, might be better than growing complacent because nothing needs to be done for 50 years. Might be setting things up for a lot of work when that next change comes due.
- hvidgaard 7y agoIt's almost as if we've tried something like that in the past, and the effort to avoid the worst issues was a monumental effort.
- tux1968 7y agoConfess I'm not quite clever enough to know what you mean or to what you're referring.
- hvidgaard 7y agoY2K problem, because someone at some point decided that two digits was enough to represent years. Thus when 99 came to an end, the clock would show 00 for year. It was an undefined behavior how to interpret it. The event was rather boring, because a huge effort went into making sure that critical infrastructure was "Y2K Ready". So my point was that pushing the problem in front of us until it becomes too large to ignore, is not a good strategy when we're talking (it) infrastructure. Handling leap seconds every now and then are the lesser evil.
- mikorym 7y ago> 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.
- hvidgaard 7y ago> Move any jumps in time to once a century (or millennium) Instead of building it into all into the protocol and time libraries, it's so far into the future that "We don't have to worry about that". We've had that issue before with Y2K. > Such jumps have occurred in the past (Julian to Gregorian) In a very different time. Today it would not be as easy - in fact since time and date are ubiquitous, it's not a simple task at all. > The idea that I don't know how many UTC seconds will pass between now and May 15, 2022 0:00:00 is absurd. If it matters for your use case, the don't use UTC time?
- Tepix 7y ago> The idea that I don't know how many UTC seconds will pass between now and May 15, 2022 0:00:00 is absurd. Not at all. To quote Feynman: "Nature cannot be fooled". The earth will rotatate in a (slightly) chaotic fashion. Midnight has a definition which is based on astronomy. Thus, you need to adjust the length of a second (which is not desirable) or the number of seconds in a day.