[HN Gopher] The leap second's time is up: world votes to stop pa...
___________________________________________________________________
The leap second's time is up: world votes to stop pausing clocks
Author : tinalumfoil
Score : 363 points
Date : 2022-11-18 17:44 UTC (5 hours ago)
(HTM) web link (www.nature.com)
(TXT) w3m dump (www.nature.com)
| warbler73 wrote:
| The earth sped up slightly the last couple years after only
| slowing down for a long time.
|
| The great leap-minute crisis of 2147 will be interesting.
| nativecoinc wrote:
| I wonder: Why is Daylight Savings/Normal Time not implemented
| using monotically increasing hours? Day goes up to hour 23 one
| time of year and hour 25 the other instead of doing a clock hour
| _twice_. Would be weird to be able to have 23-hour and 25-hour
| days. But this seems to be how leap seconds are handled (one 61
| second minute)?
| gcanyon wrote:
| It's (less than) a minute a century -- why would we not simply
| say "no corrections except at the century mark, in the middle of
| the weekend closest to January 31st"? That way:
|
| There's an exact time everyone knows the correction will happen,
| it's just a question of how big the correction will be.
|
| The correction is always in the same direction -- no "one second
| forward, then later one second back" shenanigans.
|
| It always happens over a weekend, so no one has to deal with
| real-time work-time issues.
|
| While maybe some have to work a weekend, at least it's not near
| the year-end holidays.
|
| It only happens once every 100 years.
| TheRealPomax wrote:
| I love how "the world" voted to end the leap second, before
| actually coming up with how to deal with scientific desync (Real
| world: irrelevant. Space science: kinda important)
| no_butterscotch wrote:
| Is this going to make dealing with time/time-zones/etc even more
| difficult in code now?
| Giorgi wrote:
| wait, does this mean there will be no more leap day year starting
| from 2035?
| ucarion wrote:
| The same CGPM 2022 conference also resolved to give standard
| prefix names for 10 to the 27 and 30: power
| prefix symbol 10^27 ronna R 10^-27 ronto
| r 10^30 quetta Q 10^-30 quecto q
|
| c.f.
| https://www.bipm.org/documents/20126/64811223/Resolutions-20...
| (Resolution 3, English version on page 23)
| asdfman123 wrote:
| They're just doing this so Twitter won't break, aren't they?
| ummonk wrote:
| Just use variable speed seconds.
| shadowofneptune wrote:
| The problem only arose when the second was changed from being
| 1/86400th of a solar day to being defined by atomic clocks. The
| old definition worked well for civil purposes but was by the
| 1950s impossible to accurately co-ordinate between researchers.
| Sniffnoy wrote:
| Note that what the article actually says is that there will be no
| more leap seconds _starting in 2035_. There could easily still be
| more before then.
| ars wrote:
| So we make things worse for humans in order to make it easier for
| computers?
|
| Yah, one second doesn't matter, but it builds up.
|
| This: "Or we could even decouple our sense of time from the Sun
| entirely, to create a single world time zone in which different
| countries see the Sun overhead at different times of day or
| night."
|
| Shows that they are completely disconnect from human reality:
| "Science already doesn't use local times, we talk in UTC."
|
| That's great for science, but people care about day vs night.
| Beltalowda wrote:
| > Yah, one second doesn't matter, but it builds up.
|
| I don't think it's that big of a deal; do you really care what
| the perception of "11 in the morning" is for someone 1,000
| years ago? This kind of thing is pretty cultural anyway, and a
| slow drift over a thousands of years doesn't really matter.
|
| The main reason we have the "new" Gregorian calendar is because
| of religious reasons, not because people were having huge
| practical problems with the old (slightly less accurate) Julian
| calendar.
|
| Plus the current leap second system won't really deal with the
| long-term drift anyway because the earth's rotation keeps
| slowing, so in a few hundred years we'd need more leap seconds
| than the current system allows, and eventually we'd need a
| "leap second" every day because the day is a second longer
| (around the year 6000 IIRC).
| Eleison23 wrote:
| Religion was only half the reason for the Gregorian calendar
| reform. Church and state, being interlinked and intertwined,
| the civil calendar was gradually slipping away from correct
| calibration with the equinoxes and thus the seasons. So it
| was important for farmers and mariners and politicians to all
| have a reliable calendar that matched what the Earth was
| actually going through.
|
| It just so happened that the religious authority in the West
| was able to make a significant change to the civil calendar
| which also happened to match the Church calendar, and it was
| adopted by all of Christendom, eventually even Asia and the
| four corners of the Earth have accepted it as universal and
| not so religious.
| Beltalowda wrote:
| That was I was told in history lesson, too, but I'm not so
| sure that was all that important of a reason, otherwise it
| wouldn't have taken hundreds of years for people to adopt
| the new calendar. The drift is so slow that a week more or
| less over a period of 1,000 years is easily something that
| can slowly be adjusted to by farmers, politicians, and the
| like (unlike, say, the Roman calendar before Caesar
| reformed it which drifted by several days every year).
| philwelch wrote:
| Solar noon, or the solar meridian, is the time of day in which
| the sun is highest in the sky. If our times were completely
| natural, solar noon would be at 12 PM exactly.
|
| Today, the solar meridian in Madrid is at 12:59 PM, while the
| solar meridian in Belgrade is at 11:23 AM. This is because
| Madrid and Belgrade are within the same time zone, in order to
| more easily coordinate European commerce.
|
| If that's an acceptable tradeoff, I don't really see the issue
| in drifting something on the order of dozens-to-hundreds of
| seconds per century.
| friend_and_foe wrote:
| I agree with you quite a bit here, although I'm of the
| persuasion that this one minute a century drift is nothing, you
| already deal with orders of magnitude worse when you go visit
| family in another time zone for example, and you're fine.
|
| I think this goes along the lines of the great DST debate, the
| US is going to do away with the changes next year and _make DST
| permanent._ Not do away with it, keep it, forever.
|
| Fundamentally we create these abstractions and begin to rely on
| them and then decouple how we operate from the real world. We
| created the clocks to measure the position of the sun in the
| sky, now we ignore the sun entirely, the clocks are god now. I
| don't think it's a good thing generally speaking, but on this
| particular issue, I don't think people are going to really feel
| anything different happening, it will decrease the engineering
| burden to constantly maintain and update systems, which means
| decreased resource consumption, with no noticeable impact on
| the day to day lives of anyone except those engineers relying
| on exact time measurement.
| soggybutter wrote:
| I struggle to understand how we benefit that much from the same
| wall clock times mapping roughly to the same times of day
| across time zones. It seems like there's pros and cons to both
| ways and there's no clear "better" option when it comes to the
| human experience. Meanwhile, doing away with timezones also
| does away with a lot of complexity both in computing and other
| areas (e.g. scheduling across timezones)
| ars wrote:
| This will help you understand: https://qntm.org/abolish
| alerighi wrote:
| Because we have to distinguish the two concepts. With timezones
| we already did it: computers save time (usually) in UTC format,
| and time is converted to the user time zone only when
| displaying it (at an higher level).
|
| This is obviously better, when you save a file for example you
| don't care about the region of the user, and thus the save
| timestamp of the file should really be an absolute number, so
| if you take your laptop and go from one country to another your
| whole system doesn't break because it sees timestamps in the
| future, same thing when daylight saving is applied and the
| clock is brought back/forward by an hour.
|
| Leap seconds, if we decide that we should keep them (to me not,
| because the difference is so little that we would start to
| notice that in centuries, and who knows not which computer
| systems we will have but if humanity still exists), should
| really be handled at time zone level, by shifting of an offset
| that contemplates leap seconds, and not by slowing
| up/accelerating clocks.
| CryZe wrote:
| How is this supposed to work? The rotation of the earth is not a
| constant. So we either scrap UT1 ("the atomic clock") or UTC
| ("the calendar"). Neither sound like an actual option. The latter
| would imply that at some (far off) point in the future you wake
| up at like 10pm as UTC and UT1 are now entirely mismatched (you
| may as well get rid of all time zones at that point).
| kibwen wrote:
| _> The CGPM -- which also oversees the international system of
| units (SI) -- has proposed that no leap second should be added
| for at least a century, allowing UT1 and UTC to slide out of
| sync by about 1 minute._
| jakear wrote:
| If it gets too bad we can just leap-hour back onto schedule,
| way easier. (alter the tables that hold the existing offsets -
| this is done all the time)
| kangalioo wrote:
| In my opinion, leap seconds are accumulated so slowly that the
| impact of abolishing leap seconds won't be noticeable in daily
| life for a couple hundred years.
|
| As the article said, many countries jump forwards and backwards
| an entire hour twice a year and after the adaptation period we
| don't notice
| ordu wrote:
| _> The latter would imply that at some (far off) point in the
| future you wake up at like 10pm as UTC and UT1 are now entirely
| mismatched (you may as well get rid of all time zones at that
| point)._
|
| We (or our descendants) can try to fix Earth rotation. All is
| needed is a big enough rotating mass with a variable speed of
| rotation.
| nousermane wrote:
| TAI - atomic clock, ignores earth rotation.
|
| UT1 - based on Earth's rotation only, strictly 86400 seconds
| per day; length of each second varies; takes a heck of a lot of
| effort (and time) to measure accurately.
|
| UTC - has same length of a second as TAI, but (for now) tracks
| UT1 to a precision of +/- 1 second. To achieve that, can have
| days that are 86399, or 86400, or 86401 seconds long.
|
| None of 3 is planned for scrapping. The only change discussed
| in TFA is to fix UTC day to 86400 seconds (at cost of letting
| it drift further away from UT1).
| CryZe wrote:
| Oh right, I confused the terminology, but the point still
| stands mostly.
| Vvector wrote:
| It's a minor problem. One minute off in a hundred years is
| something we can all live with.
| krick wrote:
| I'm not saying that we can't, but saying that we can
| seems quite brave (and by "brave" I mean foolishly
| reckless) without actually trying it. I, for one, am not
| so sure. There is a lot of stupid stuff about calendars
| and clocks (of which DST is worst by far), but at least
| nothing is really drifting.
|
| Is it important that midnight is actually midnight? I
| don't know. I would prefer it to be, but perhaps I can
| just update my knowledge on when the midnight actually is
| once or twice a year. Perhaps it isn't a big deal at all.
| But I wouldn't dare to claim that "surely there can be no
| problems with it".
|
| And, yes, that kinda means I don't support the leap
| second removal. It wasn't great, but eventually fixing
| the software written by incompetent people sounds more
| like a solution, than breaking the existing solution and
| making both competent and incompetent people alike
| eventually come up with a new one (to abolish it as well
| after 100 more years).
| Vvector wrote:
| > Is it important that midnight is actually midnight?
|
| Midnight is almost never at midnight.
|
| Let's talk noon, specifically solar noon, as it is easier
| to visualize. Solar noon varies throughout the year, and
| based on the position in the timezone.
|
| Solar noon for two cities in Eastern Time Zone: 11:29:16
| - Boston 12:22:36 - Atlanta
|
| Tomorrow, solar noon in Atlanta will be 12:22:50, 14
| seconds later than today. No one notices a 14 second
| shift from one day to the next. As you can see, solar
| noon is almost never at clock noon, yet no one complains
| about that. Who would notice a 1 minute shift over 100
| years?
|
| The programming problem is made vastly more difficult
| because the leap seconds are not known in advance. When a
| new leap second is announced, every dependent system has
| to be updated.
| TremendousJudge wrote:
| Can GPS handle this? Or is it under a different time
| standard?
| zokier wrote:
| GPS has its own time thing, kinda fixed offset from TAI
| iirc
| falcor84 wrote:
| The article mentioned GPS uses UT1
| [deleted]
| vilhelm_s wrote:
| I propose waiting a thousand years, so that the difference
| builds up to an hour, and then handle the adjustment as part of
| the daylight savings reform, which should just about have
| worked its way through the U.S. Congress and the EU
| institutions by then.
| vlovich123 wrote:
| No. You'd need to actually change all the calendars. for
| example, an event recorded as happening at UTC 0 doesn't get
| changed by a time zone change. And yet the hour you've
| accumulated is a "real" hour that's accumulated in the number
| of seconds you think has elapsed since 0. You could of course
| keep track of when those leap seconds applied but now you
| have to have an almanac to compute the difference between two
| time stamps to account for all the smearing.
| testplzignore wrote:
| UTC is the atomic clock (TAI minus 37 seconds currently); UT1
| is "Earth time".
|
| We would use UTC. UT1 would end up only being used by
| astronomers and whoever else cares about the Earth's rotation.
|
| By the time UTC and UT1 diverge enough to matter, humanity will
| have either destroyed itself or come up with a new time
| standard.
| Dylan16807 wrote:
| So there are two things to note. First is that it takes a
| _long_ time for the seconds to add up, and second is that when
| we 're looking into the deep future the current system of leap
| seconds won't be enough even if we do keep them.
| Klasiaster wrote:
| Most systems rely on network time from a canonical time source.
| Wouldn't it be enough to do the leap second smearing/adjustment
| there to free the end systems from dealing with that?
| alex_young wrote:
| Why use leap seconds at all?
|
| Our current calendar was introduced in 1582, 440 years ago [0].
|
| We add a leap second about every 1.5 years [1].
|
| That means in the time since our calendar was invented, we've
| added less than 5 minutes to our time.
|
| Would anyone notice if noon arrived 5 minutes earlier over the
| course of 500 years? Especially since the position of the sun
| varies orders of magnitude more than that simply based on season?
|
| Maybe we could all just agree to add 10 minutes in 3022. If we
| haven't switched calendars again.
|
| [0] https://en.wikipedia.org/wiki/Gregorian_calendar [1]
| https://www.timeanddate.com/time/leapseconds.html
| euroderf wrote:
| Hot take: Leap seconds caused by astronomers refusing to modify
| their own software, instead getting the rest of the world to
| modify theirs. Too facile?
| mjevans wrote:
| Doesn't astronomy already use their own time reference
| standard?
|
| It seems like JPL (NASA) and the scientific community have
| defined two currently used sets of time standards for
| observations from Earth and from space near Earth.
| https://en.wikipedia.org/wiki/Time_standard#Time_standards_f...
| Barycentric Coordinate Time (TCB) and Geocentric Coordinate
| Time (TCG) with DE430 as the current revision of their standard
| https://en.wikipedia.org/wiki/Jet_Propulsion_Laboratory_Deve...
| dmm wrote:
| More like lazy programmers want everyone to change basic
| timekeeping practices just so they don't have to fix their
| code.
| 4str0n0mer wrote:
| Very much so.
|
| Look at astronomical software, e.g. xephem. There will be a
| "clocks" tab that displays a number of different clocks, TAI
| (atomic clock, no leap seconds), UTC (global civil time), media
| solar time (GMT, which ISN'T UTC) and finally, derived from the
| aforementioned "sidereal time", which is the one you really
| need to adjust your telescope. Sidereal time is derived from a
| year with 1 more day basically, because the earth moving around
| the sun adds 1 more rotation of the background stars. Which is
| a drift of roughly 4 minutes per day.
|
| https://en.wikipedia.org/wiki/Sidereal_time
|
| Oh, and then there is stuff like Julian date which you need to
| look up the myriads of catalogues and tables you need for
| corrections because everything "wobbles" even more than you'd
| think.
|
| Yes, dropping leap seconds will remove 1 table lookup from the
| above. But astronomical time systems are so complex that that
| change is a drop in the ocean.
| euroderf wrote:
| (insert link to canonical "standards" xkcd)
| dexwiz wrote:
| Any modern positioning system needs an accurate clock. Leap
| seconds aren't completely predictable, so you can't deploy
| something like a GPS unit with future leap seconds encoded.
| These computers are often spread across vast distances, so it's
| the most difficult thing to possibly update.
| jasonwatkinspdx wrote:
| Yup, too facile.
|
| Astronomy commonly uses TAI or raw GPS time. In fact if you
| look at video footage from NASA control rooms and such there's
| usually a GPS second clock up on the wall somewhere.
|
| The motivation for leap seconds wasn't astronomers, but to just
| keep civil time tied to solar time long term. However, the
| unpredictability of these leap second additions has proven to
| be pretty annoying, causing bugs and such. This is why google
| and others actually "smear" the introduction of their leap
| seconds over half the day.
|
| Considering the current difference is 37 seconds, its natural
| to wonder if this is worth it. Certainly most people wouldn't
| notice relative to dawn dusk for a very long time, long enough
| that the entire concept probably wouldn't even make sense
| anymore. So why not just stop? That's the basic argument here.
| [deleted]
| adamsb6 wrote:
| Currently software has to be built to accommodate leap seconds.
| They happen frequently enough that you'll find out within a few
| years whether your software breaks when time suddenly skips
| forward or backward.
|
| If we kick the can down the road such that eventually we'll need
| to add a leap minute, we're going to end up with software that
| was never written to expect time to change in such a way, hasn't
| had a real world test of the change for decades, and will have no
| one working on the software who ever had to deal with such a
| change.
|
| It's going to be much worse for software reliability to have a
| leap minute on the order of once a century than a leap second
| every few years.
| bombcar wrote:
| I've always thought that the best way would just have leap
| seconds every six months, and have it be +- 1 second _no matter
| what_ - so sometimes you 'd go back a second twice in a row,
| and then go forward a second to get back to correct.
|
| That'd test all the software paths.
| layer8 wrote:
| Better make it every other day rather than every six months.
| bombcar wrote:
| Henceforth every minute will be "bell curve distribution
| around 60" seconds long, and each hour will be "bell curve
| distribution around 60" minutes long.
|
| This variability will provide excellent fuzzing of all time
| libraries everywhere.
| eternityforest wrote:
| It would test all the software paths in production though.
| Bad software would still fail and need last minute patches
| every 6 months.
| thfuran wrote:
| Making time less accurate just for the sake of testing in
| production doesn't seem great.
| gpvos wrote:
| From 2035 it's going to be less accurate in exactly the
| same way. I'd argue bombcar's method is more robust.
|
| I don't know of anything that actually _requires_ UTC to be
| within 1 second of average rotation-based time; having it
| within 2 or 3 seconds is extremely unlikely to actually
| break anything. But we do generally want to have measured
| time roughly in line with Earth time in the medium to long
| term.
| SonOfLilit wrote:
| Today it is within I think +-3 hours of earth time (China
| being the worst offender), because of timezones and DST.
| If it ever gets worse than half an hour in a country,
| they can always change the timezone... or just, like,
| change businesses' opening hours and stuff.
| cactus2093 wrote:
| > That'd test all the software paths.
|
| The daylight savings time bugs I've run into at pretty much
| every company I've ever worked at would beg to differ.
| throw0101a wrote:
| See also leap year bugs even though that concept has been
| around even longer than DST.
| FeistySkink wrote:
| My favorite is comparing aggregated data across several
| time zones when DST changes happen.
| nostromo wrote:
| Nobody really cares about clocks being celestially "off" by a
| minute either.
|
| So this isn't a once-a-century thing, it's adding-a-
| leap-15-minutes-once-a-millenia issue.
| capitainenemo wrote:
| https://royalsocietypublishing.org/doi/10.1098/rspa.2016.040.
| ..
|
| Odd. I was wondering how fast it actually was long term, and
| this rate from historical record seems much lower. They cite
| 1.8ms/century if I'm reading it correctly with some odd
| cyclical thing going on. " the change in the length of the
| mean solar day (lod) increases at an average rate of +1.8 ms
| per century. "
|
| I mean, we've added 22 _seconds_ over 50 years. Although at
| current rate it would still just be 7 minutes after a
| millenia :)
|
| _edit_ You know, nevermind, that 's all covered on
| wikipedia. https://en.wikipedia.org/wiki/Leap_second#Slowing_
| rotation_o...
| layer8 wrote:
| The rate accelerates long term, but yeah.
| agrajag wrote:
| The rate of drift is so slow that people will never care.
|
| Even over thousands of years when an hour of drift is
| accumulated there won't be a manual adjustment - people will
| have just gotten used to different times of day having
| sunlight, with generations having been born and died with mean
| solar time happening at 11am.
|
| Eventually the rotation of the earth may change enough that
| drift accumulates too quickly and leap time needs to be added,
| but that's only going to be true thousands to tens of thousands
| of years in the future.
| [deleted]
| smcameron wrote:
| Nah, you just smear time faster or slower so you never need to
| "leap".
| cptskippy wrote:
| In an enterprise environment, every leap second or TZ change
| invokes a ceremonious updating of anything using Java or a JVM.
| I suspect a lot of people would rather perform a once a century
| update than the bi-annual process they do now.
| gpvos wrote:
| The thing is that there will be entire Java-like ecosystems
| that will have shorter longevity than the time between leaps.
| So practically all of them will have no facility for a leap
| _at all._
| MonkeyClub wrote:
| Did we just create a Cobolesque Y2K situation for Java?
|
| I can just imagine Graybeards of the future rushing ahead of
| the leap minute to update the JVM lest the world goes in
| flames yet again.
| zh3 wrote:
| Indeed; the converse would be to add (or remove) micro-
| leapseconds in order to keep accurate time. That way it would
| happen so often that the code would get tested and we'd have
| working implementations (maybe we could fix the traditional
| Apple issues with leap years at the same time).
| layer8 wrote:
| I'm pretty sure we would get bugs whenever the accumulated
| micro-leapseconds would reach a full second.
| zh3 wrote:
| Mmm...true, some programmers even have problems with
| gettimeofday().
|
| The point still stands though - common problems have tested
| code, uncommon/rare problems rarely have battle-hardened
| solutions.
| worik wrote:
| > Currently software has to be built to accommodate leap
| seconds
|
| Plenty is not.
|
| The Swift time type ignores them in its implementation. I filed
| an issue, and they said there were no plans to implement them.
|
| Good choice it turns out.
|
| Who would of thought that adding a second on random new year
| changeovers would be worse than letting clocks drift.
|
| Me for one.
|
| We can have a "leap hour" in a thousand years. Till then do we
| care, I do not, if the clocks and the sun drift very slowly
| apart from each other?
| philwelch wrote:
| It's going to be centuries until the difference between
| astronomical midnight and UTC midnight is more than an hour,
| which is the exact same amount of error we deliberately inflict
| on ourselves to have more daylight in summer evenings and half
| the error that residents of Spain experience by as a
| consequence of the political decision to join the same time
| zone as Berlin. If human civilization exists long enough for
| this to be an actual problem, we're probably going to have to
| figure out how to coordinate time with multiple space
| settlements, which is going to be a much harder problem thanks
| to time dilation.
| nousermane wrote:
| You're right, but I'd argue this problem is already here.
|
| Thanks to glaciers melting, earth rotation is (temporarily)
| accelerating. Because of that, positive leap seconds, regular
| before, didn't happen since 2017 - so there could very well be
| (recent) software out there that has that code-path broken, and
| nobody noticed yet.
|
| And due to exact same geophysical effect we might see a
| negative leap second - something that never ever happened
| before. What are the odds that every single piece of software
| gets that one right?
| zh3 wrote:
| Interesting point. Just like a skater pulling their arms in,
| snow melting and running to lower ground would make the earth
| spin faster (and let's add in the extra erosion). Sea levels
| are rising though (due to both thermal expansion and runoff).
|
| Be interesting to estimate the size of the various effects
| (no doubt I've missed plenty of others) but is it really true
| that a change in sign of the acceleration of Earth's angular
| velocity is down to climate change?
| umanwizard wrote:
| Why would we ever need a leap minute? Just let time zones
| drift. Unless you happen to be at the exact longitude for which
| your time zone is correct, the sun's not at its highest point
| in the sky for you at exactly noon anyway.
|
| Eventually, thousands of years from now when time has drifted
| by an hour or more (assuming modern technological civilization
| even still exists by then), each jurisdiction can just change
| their time zone's offset from UTC, without coordinating with
| anyone else. Jurisdictions making time zone changes is a well-
| understood situation that we already know how to deal with.
| AnotherGoodName wrote:
| The last part is right and is also why we have this problem.
|
| Leap seconds are an architectural blunder that always
| belonged in the abstraction layer that lines up the sun with
| the rotation of earth (the time zone abstraction). It never
| belonged in the part that counts seconds.
| umanwizard wrote:
| That's a great way of putting it!
| colinsane wrote:
| clocks get used for two distinct purposes, often at odds:
|
| - the measurement of durations.
|
| - the presentation of some timestamp in a way that the reader
| has some intuition for.
|
| that first purpose won't be hurt by not tracking leap seconds.
| actually, a lot of applications will probably more accurately
| measure durations by eliminating leap seconds.
|
| if leap seconds (or minutes) really are of critical importance,
| we'll reintroduce them to the presentation layer. the thing is,
| very few people can tell the difference between 12:01 and 12:02
| without being told the "real" time. so if you're presenting a
| time which is "off" by a minute because there's no leap
| seconds... does it really matter?
| zimzam wrote:
| Why bother? A calendar year is 365.242 days long... time is
| already off by about 3/4 of a day the year before a leap year,
| what does adding a second here or there really do?
| krick wrote:
| Time is not off by about 3/4 of a day, calendar is. And
| hardly many people care about planet's position relative to
| the Sun (on the orbit) -- I mean, they can, if it is
| important for they occult rituals or something, but probably
| they learned to work with it over the centuries already.
|
| Earth's rotation relative to the Sun is whole another deal.
| unilynx wrote:
| Well actually people did, or we'd still be on the Julian
| calendar.
| charcircuit wrote:
| There has never been a negative leap second.
|
| >If we kick the can down the road such that eventually we'll
| need to add a leap minute
|
| The drift is not in a single direction. The total drift is not
| going to be significant for a very long time if ever.
| layer8 wrote:
| The total drift is accelerating long term, because the tidal
| deceleration of Earth's rotation due to the moon is
| quadratic.
| worik wrote:
| It will be an urgent crises in a century, a millennium...
| throw0101a wrote:
| > _There has never been a negative leap second._
|
| That doesn't stop the (e.g.) FreeBSD folks run tests to make
| sure things are fine:
|
| * https://lists.freebsd.org/pipermail/freebsd-
| stable/2020-Nove...
|
| * https://docs.freebsd.org/en/articles/leap-seconds/
|
| Of course there's a whole lot of other userland code besides
| _ntpd_.
| blippage wrote:
| Well that didn't long, did it? It was introduced in 1972.
|
| In years to come historians will be having a good old chortle
| about how we managed to come up with two times that were 37
| seconds apart.
|
| In retrospect, fiddling with computer clocks like that was bound
| to be a nightmare.
| 1970-01-01 wrote:
| I didn't get a vote. Did you?
| hoytech wrote:
| In 2015 I was working at a "fintech" company and a leap second
| was announced. It was scheduled for a Wednesday, unlike all
| others before which had happened on the weekend, when markets
| were closed.
|
| When the previous leap second was applied, a bunch of our Linux
| servers had kernel panics for some reason, so needless to say
| everyone was really concerned about a leap second happening
| during trading hours.
|
| So I was assigned to make sure nothing bad would happen. I spent
| a month in the lab, simulating the leap second by fast forwarding
| clocks for all our different applications, testing different NTP
| implementations (I like chrony, for what it's worth). I had heaps
| of meetings with our partners trying to figure out what their
| plans were (they had none), and test what would happen if their
| clocks went backwards. I had to learn about how to install the
| leap seconds file into a bunch of software I never even knew
| existed, write various recovery scripts, and at one point was
| knee-deep in ntpd and Solaris kernel code.
|
| After all that, the day before it was scheduled, the whole
| trading world agreed to halt the markets for 15 minutes
| before/after the leap second, so all my work was for nothing. I'm
| not sure what the moral is here, if there is one.
| karmakaze wrote:
| Couldn't your "fintech" company decide to halt trading 15-min
| before/after on its own without the agreement of the trading
| world?
| hcrisp wrote:
| Reminds me of the story of the computer engineer at Data
| General in Traccy Kidder's nonficion book, "The Soul of a New
| Machine" [0], who quit after spending weeks toiling away on
| sub-second timing concerns:
|
| > He went away from the basement and left this note on his
| terminal: "I'm going to a commune in Vermont and will deal with
| no unit of time shorter than a season."
|
| [0] https://en.m.wikipedia.org/wiki/The_Soul_of_a_New_Machine
| xwolfi wrote:
| What should I say, trying to go sub millisecond, one
| profiling run at a time, sigh...
| Konohamaru wrote:
| Maybe he should get Stephen Colbert's second-by-second day
| planner.
| gnu8 wrote:
| It is a uniquely crummy feeling to have your work go unused
| like that, but you shouldn't let it discourage you. You reached
| a level of mastery on this particular thing that few people
| have, which is evidenced by the fact that no one else in the
| trading community was able to reach your company's level of
| confidence and they decided to wait out the leap second
| instead.
| a9h74j wrote:
| > no one else in the trading community was able to reach your
| company's level of confidence
|
| So his work contributed to community wisdom, and that
| influential community has probably had some say in cancelling
| leap seconds. I wouldn't call his work wasted. I would call
| that notably _few_ degrees-of-separation in making an
| observable difference.
| bahmboo wrote:
| You got paid to dig extremely deeply into a very complex and
| important problem spanning multiple systems and domains. You
| developed a plan, tested it and were ready to act.
|
| This is a hugely valuable learning experience few people even
| get a chance at, let alone solve. Too bad it doesn't show up on
| your resume is the only downside!
| oblio wrote:
| Resume, no.
|
| Interview discussion? If you're any good at interviewing, it
| should.
| modernpink wrote:
| >I spent a month in the lab
|
| Do you mean at your desk? What is a lab in a fintech context?
| martyvis wrote:
| For most of us that are doing implementation engineering, a
| lab is simply a collection of the gear that can be put
| together in a simulation of the production environment
| without being constrained by formalities. For me it would be
| a bunch of network and server kit and cables in a rack.
| mgsouth wrote:
| Not OP, but at several jobs our labs were small server rooms
| stuffed with network gear, servers, and client PCs. They were
| used for end-to-end simulations and tests. It wasn't uncommon
| to actually do work in the lab, keeping an eye on the blinky
| lights or somesuch.
| RGamma wrote:
| Seems really easy to miss sonething. You think it would have
| worked out ok?
| TOGoS wrote:
| > I'm not sure what the moral is here
|
| I think the moral is that it'd be a lot easier if we could just
| stop messing with the clocks, or at least push more technical
| things towards only caring about a closest-to-a-global-high-
| precision-monotonic-clock-as-relativity-allows rather than
| worrying about what the clocks on the walls say, which is more
| a personal matter of how much you care or don't where the sun
| is in the sky at 12:00:00.000.
| alexfromapex wrote:
| The moral is it's a waste of time either way
| pmontra wrote:
| Contingency plans have their own contingency plans. Maybe
| trading companies started talks to stop the market months
| before your company assigned that task to you, in case of no
| agreement or a negative one.
| tsol wrote:
| Moral of the story is that insurance is expensive
| eointierney wrote:
| You did the good job
| msla wrote:
| Don't conclude it's that hard for everyone until you've spoken
| to a good subset of different people.
|
| You're conscientious and willing to dig in to the details to
| fix a problem. Plenty of people aren't, and plenty of those are
| doing the same job as you. Look up from your own little world
| and try to figure out what other people are doing, how they're
| doing it, and why. This applies generally: If you fixate on a
| specific language or toolkit, you'll miss others which fix or
| obviate bugs you were resigned to living with. Same with OSes
| and environments. It even applies to relationships, which is
| why a big hallmark of abuse is isolating the victim.
| ilyt wrote:
| We just enabled leap second smearing on chrony.
| mikepurvis wrote:
| I think that's the only reasonable way to handle this kind of
| thing, though I bet that accurate time matters enough in
| fintech that you'd still have some cases where you'd need
| access to the "true" wall time in order to stamp logs for
| auditing or whatever.
| pfarrell wrote:
| I think the moral is, "those who fail to prepare are preparing
| to fail".
| Shared404 wrote:
| The moral is we get to hear your cool war story. Thanks for
| sharing!
|
| ...okay yeah that's not a moral, but still.
| dylan604 wrote:
| >I'm not sure what the moral is here, if there is one.
|
| Apparently, its about as useful as the leap second itself ;)
|
| I feel your pain though, as I've spent weeks on something only
| for it to be tossed away like it was nothing at the last
| second. I guess that's how Google devs feel when their projects
| are deprecated. At least theirs saw the light of day and
| provided some validation
| rkagerer wrote:
| Here, have a bright shiny imaginary internet point. It doesn't
| nearly do justice but thanks in any case for sharing your
| story.
| svara wrote:
| The moral of the story is that laziness is a virtue. Think of
| all the time that could have been saved, had you had no plans
| like your partners ;)
| jimmaswell wrote:
| Think of all the time that could be better appropriated than
| on fintech in general. Seems like such a waste of resources
| siccing a bunch of computers against each other in a zero sum
| game of stock arbitrage. I will admit some of the stuff tech
| comes out of it is cool on its own at least.
| kortilla wrote:
| Yeah, they could have been working on something truly
| valuable like violating people's privacy with ad-tech. Or
| maybe sucking millions of hours of people's lives away with
| TikTok algo improvements. Maybe they could be working on
| the next MoviePass!
|
| > zero sum game of stock arbitrage.
|
| By your definition insurance is zero sum as well. But
| people find that generally useful. Taking risk off of
| peoples hands has value even if a widget doesn't come out
| the other end.
| throw827474737 wrote:
| > Yeah, they could have been working on something truly
| valuable like....
|
| But why not just a reasonable product? Yes, what could
| that be, there cannot be something that is fairly priced
| and people really want, need, what just helps. Not today
| anymore!
|
| > By your definition insurance
|
| I know what you try there and on a very abstract level
| you are maybe slightly right, but PLEASE no, high level
| gambling (==milliseconds&millions) is not at all
| comparable to the insurance model in many regards,
| foremost maybe purpose for the community?
|
| (and its pretty clear that fintech here sure doesn't mean
| the classical bank and modern "normal" payment system...
| ).
| worik wrote:
| > Seems like such a waste of resources siccing a bunch of
| computers against each other in a zero sum game of stock
| arbitrage
|
| Despite the useful service of price discovery (here are so
| many better ways) it is clear from the EMH that those
| computers are not doing arbitrage, they are front running
| trades.
|
| Illegal. Criminal in USA (I think). But makes billions and
| billions for the already very rich. So that is why there is
| so much of it
| kevinventullo wrote:
| Someone has to make the EMH hold.
| arcticbull wrote:
| Fintech covers the entire payments space too
| jimmaswell wrote:
| Guess I'm thinking more of HFT. Normal payment processing
| isn't this affected by a leap second though as far as I
| know.
| divbzero wrote:
| This is a good story regardless, but if you do want to derive
| some morals from the experience:
|
| - Seemingly simple tasks can be more complex than you expect
| ("add a leap second on this Wednesday")
|
| - Real world systems can be more complex than you expect
| ("bunch of software I never even knew existed")
|
| - Planning and testing can make a big difference vs. just
| winging it ("a bunch of our Linux servers had kernel panics for
| some reason")
|
| - Success can be a non-event that goes unnoticed ("everything
| worked and no money went missing")
|
| - Sometimes the best solution is not a technical solution
| ("halt the markets for 15 minutes before/after")
| yreg wrote:
| >Sometimes the best solution is not a technical solution
| ("halt the markets for 15 minutes before/after")
|
| We've had an election recently, right on the day when DST
| changed. On the night of counting of the votes, the clock
| went 2:59 AM -> 2:00 AM.
|
| To save themselves trouble the Statistics Office instructed
| all vote counters that under no circumstances are they to
| enter or update anything in any system during the repeating
| hour until it's 3:00 AM the second time...
| codetrotter wrote:
| The interesting thing about DST is that it's not really
| repeating the hour, if you include the time zone offset in
| your time stamp.
|
| Here, look. Using the time zone for Norway in this example,
| with the `date` command on macOS.
|
| First the last second before DST ended in Norway this year.
| TZ=Europe/Oslo date -I seconds -jf %s 1667091599
| 2022-10-30T02:59:59+02:00
|
| Then the second after. TZ=Europe/Oslo
| date -I seconds -jf %s 1667091600
| 2022-10-30T02:00:00+01:00
|
| So while people say that time went from 02:59:59 to
| 02:00:00, I see it as time going from 02:59:59+02:00 to
| 02:00:00+01:00 :)
| a9h74j wrote:
| > Sometimes the best solution is not a technical solution
|
| I once came across an early 1950s Scientific American article
| by Bertrand Russel, IIRC. It included a cartoon.
|
| Frame one: Computer beats man at chess.
|
| Frame two: Man unplugs computer.
| quickthrower2 wrote:
| A bit like buying car insurance and not claiming. Still
| possibly worth it.
| [deleted]
| kqr wrote:
| I was gonna say, why not just close all positions and turn off
| the computers around the leap second? How much are you
| realistically gonna lose by missing a few minutes of trading,
| compared to the alternative risk?
|
| Edit: I guess the other way to look it is I guess now how much
| you can make on a few minutes of trading, seeing that it was
| worth putting at least one software engineer on it for a long
| time despite the risks...
| alfalfasprout wrote:
| It can be extremely costly to close positions (often from a
| tax perspective this is a big-no no in some cases too).
| prottog wrote:
| It's the software engineering equivalent of the crypto nerd
| with the super-strong encryption, beat by a five-dollar wrench
| attack[0]. ;-)
|
| Sometimes the best (for some definition of best) solution to a
| problem is to side-step it entirely.
|
| [0]: https://xkcd.com/538/
| programmarchy wrote:
| Moral of the story is that sometimes social engineering is much
| cheaper and more effective than software engineering!
| dpkirchner wrote:
| The moral is that sometimes we humans can choose not to let the
| perfect be the enemy of the good (enough).
| ycombobreaker wrote:
| Sometimes it pays to be the most-prepared among your cohort. In
| this case, it would have paid _so well_ that your cohort
| decided to work around it.
|
| It always pays to not be the least-prepared among your cohort.
| You'll get no sympathy if you're at the back of the pack,
| you'll just die.
| xmprt wrote:
| Another moral of the story could be that sometimes it's best
| to have a people solution to a technical problem.
| justinpombrio wrote:
| > I'm not sure what the moral is here, if there is one.
|
| Always procrastinate :-)
| jasonwatkinspdx wrote:
| I'm' baffled by the section about GLONASS. Russia surely has the
| ability to decide whether they add or remove future leap seconds?
| friend_and_foe wrote:
| Of course they do. But government bodies and other
| institutional bodies incarnated these standards organizations
| in order to better coordinate with one another, and decided and
| committed to defering to them a long time ago. Russia is a
| sovereign state, they can make any decision they want to, but
| they decided and agreed at some point to defer to this
| organization for a reason.
| clnq wrote:
| > Or we could even decouple our sense of time from the Sun
| entirely, to create a single world time zone in which different
| countries see the Sun overhead at different times of day or
| night.
|
| A very interesting idea, but probably much too progressive.
| micah94 wrote:
| I'm for this. Get rid of timezones, AM, PM, DST, leap years,
| seconds, all of it! Imagine having to know just one time. It
| takes a bit to wrap your head around. But only because we've
| accepted all the confusion for so long. The sun is still going
| to be "up" in one part of the world and "down" in another. The
| little numbers on your clock don't change that. Why can't it be
| the same little numbers everywhere?
| Vvector wrote:
| I'm for that as well. Some minor issues that I've thought of.
| Currently the day changes (Mon -> Tue) at midnight local
| time. If the day followed UTC, then would California change
| from Mon->Tues at midnight UTC, which is 4pm currently?
| magnio wrote:
| How do you know whether the sun is up or down in a place when
| all places have the same time?
| clnq wrote:
| I see people bringing this question up as a counter-
| argument for a unified time.
|
| But how do you know whether the sun is up or down in any
| given place on Earth right now? You probably don't, if the
| place is a few thousand miles East or West from where you
| are. You'd have to look up its time zone. And doing that
| might not be that much different from looking up at what
| hour the solar noon is somewhere else.
| [deleted]
| nativecoinc wrote:
| It's fundamentally the same lookup.
| __david__ wrote:
| At that point you may as well go with beats:
| https://en.wikipedia.org/wiki/Swatch_Internet_Time
| soggybutter wrote:
| I've wanted to do this for years. Every time I mention this to
| someone I get a surprisingly visceral reaction against it even
| when they can't think of any real reasons why this would be
| bad.
| Dylan16807 wrote:
| I absolutely do not believe that nobody has given you a
| coherent list of reasons.
| soggybutter wrote:
| I didn't say no one ever has, just that there's a very
| strong negative reaction even when they don't have
| reasoning for it
| Dylan16807 wrote:
| Do they really not have a reason or do they not want to
| put in 15 minutes of effort to explain something that has
| already been explained a thousand times?
| amflare wrote:
| I mean, if chaos is the goal, then sure... Let me refer you to:
| https://qntm.org/abolish
| schlowmo wrote:
| > Do normal humans publish "waking hours"? Not typically.
|
| I believe I just fell in love with that idea. If this would
| become a social norm people would maybe stop trying to reach
| me in the morning.
|
| And I would know if it's too late to call others.
| lifthrasiir wrote:
| This can indeed happen when a significant portion of
| humanity lives in the space, and can trigger the biggest
| change to how we keep date and time.
| unilynx wrote:
| No need to wait that long - plenty of incoming email has
| "My working days are: " in their footer. I'm sure time
| can be added there too
| jl6 wrote:
| Man, between this and the Ronna and the Quetta, it feels like
| science is getting its admin done today!
| Kronopath wrote:
| That's because both came from the 2022 General Conference on
| Weights and Measures of the BIPM.
|
| https://www.bipm.org/documents/20126/64811223/Resolutions-20...
| selimthegrim wrote:
| Well Quetta gets in the news for different reasons for once
| btbuildem wrote:
| > Although human timepieces have been calibrated with Earth's
| rotation for millennia, most people will feel little effect from
| the loss of the leap second. "In most countries, there is a one
| hour step between summertime and winter time," says Arias. "It is
| much more than one second, but it doesn't affect you."
|
| I find this off-hand comment dismissive and out of touch. The
| semi-annual switch from Daylight Savings to "normal" and back
| again is absurd, and far from not affecting anyone. Studies show
| that productivity drops for about a week following the change
| [1], and there is a marked increase in road fatalities after the
| clocks are adjusted [2].
|
| If anything, this leap second business is what's irrelevant to
| everybody except a handful of obscure boffins.
|
| [1] https://www.healthline.com/health-news/daylight-saving-
| can-m...
|
| [2] https://www.boston.com/news/jobs/2016/03/16/daylight-
| saving-...
| colinsane wrote:
| agreed. i'm sick of being gaslit twice a year when i go to bed,
| set an alarm for 8 hours from now, and instead it wakes me
| after 7 or 9 hours while insisting it's really been 8 hours.
|
| it happened again to me just a few weeks ago with the DST
| switch. i was so mad when i learned that everything had felt
| off the day of the switch because it _was_ off that i just set
| all my clocks to UTC. no more gaslighting: my clocks all
| accurately measure intervals with no tricks, which is exactly
| what i most want out of my clock.
| SamBam wrote:
| > Leap seconds aren't predictable, because they depend on to
| Earth's natural rotation.
|
| This is surprising to me. Is the Earth's rotation so arbitrary?
| gricardo99 wrote:
| It would surprise me if we could not measure and detect any
| variation in the earth's rotation. A leap second is on the
| order of less than 0.000001% variation, at least according to
| the leap seconds applied recently.
| mananaysiempre wrote:
| More like the precision of +- 0.5 seconds / year, that is to
| say 15 parts per _billion_ , is that ludicrous. For comparison,
| time acceleration in geostationary orbit due to general
| relativity is somewhat less than one part per billion.
| Household tools (other than clocks) rarely go beyond a percent,
| and if you need a particular quantity you don't have a ready-
| made tool for you'll likely going to be hard-pressed to go
| beyond ten percent.
|
| The more precise you want to be, the more complex and numerous
| physical phenomena you need to consider become; with a system
| as involved as the Earth, at some point you get to weather-like
| chaotic behaviour, so no practical amount of additional
| precision in input data helps anymore.
| bioemerl wrote:
| Nearly all things in nature spite our systems.
|
| The earth even speeds up and slows down in response to stuff
| like earthquakes and volcanoes.
| 4str0n0mer wrote:
| a-priori wrote:
| Yes it varies unpredictably based on changes in the
| distribution of mass within the Earth from magma flows, air
| currents, ice pack movements, ocean currents, and so on.
|
| https://en.wikipedia.org/wiki/Day_length_fluctuations
| golemotron wrote:
| We're going to regret this in 10,000 years.
| puffoflogic wrote:
| I trust we will also be getting rid of leap years: that whole
| pausing the calendar for a day thing is very confusing.
|
| Oh wait, that's not how it works. And neither is it how leap
| seconds work.
| friend_and_foe wrote:
| Those are very different scenarios, they aren't equivalent.
|
| Leap years have to do directly with the sun, what day and time
| the equinoxes happen every year and the like. This time
| noticeably drifts every year, even every day, computers or not.
|
| These leap seconds and what not have to do with very sensitive
| instruments measuring time very precisely. These time measures
| are entirely about machines.
| e63f67dd-065b wrote:
| The full resolution can be found here
| https://www.bipm.org/documents/20126/64811223/Resolutions-20....
|
| To quote the relevant section:
|
| > [the CGPM] decides that the maximum value for the difference
| (UT1-UTC) will be increased in, or before, 2035
|
| > [CGPM requests that the ITU] propose a new maximum value for
| the difference (UT1-UTC) that will ensure the continuity of UTC
| for at least a century
|
| I think there are a few possible interpretations of this:
|
| - We'll readjust UTC in a century (why would you do this to
| yourself, please no, nobody wants this) by setting a predicted
| maximum that'll last 100 years
|
| - The maximum is now 1 hour, we'll adjust clocks the same way we
| adjust for DST
|
| - The maximum is infinite, UTC is now TAI + the same integral
| offset forever
|
| I'm hoping for the last one, but who knows. They've once again
| kicked the can down the road to the next 2026 meeting to decide
| what the increase in max UT1/UTC difference will look like.
| jamesgreenleaf wrote:
| Let's fix the root of the problem and make Earth's rotation
| constant. How hard could it be? /s
| bilsbie wrote:
| I didn't vote for this.
| alerighi wrote:
| I never really understood why we need leap seconds. Or better:
| why we need to bother with them in a computer system at lower
| level.
|
| If we decide that we absolutely need to keep our time in sync
| with the rotation of the earth, really what should be done is
| define a timezone with all the leap seconds applied, and use that
| timezone to only display it to the end user. Not change the way
| we sync computer clocks for no reason! NTP shouldn't contemplate
| leap seconds, for example...
| [deleted]
| jylam wrote:
| It seems I've got an unpopular opinion reading the comments here,
| but having some leap seconds from time to time ensure we are able
| to manage them. But "no leap second should be added for at least
| a century" _ensures_ there will be a y2k reckoning every century.
| Seems short sighted to me, even if it is not a game-changing
| issue, let 's be honest.
| charcircuit wrote:
| Leap seconds are not useful. We do not need to use them
| anymore. While yes you are right in that more leap seconds
| makes it easier to handle leap seconds, it is just better to
| not have to worry about leap seconds altogother. It is unneeded
| complexity that helps no one.
| ender341341 wrote:
| Why have them at all? how many people do things where they
| actually matter? at the current rate it'll be ~9000ad before we
| hit an hour offset, and we do hour offsets twice a year, so if
| an hour off is okay why is 1 second off not?
| yreg wrote:
| By that time we should be an interplanetary species and have
| a bigger time coordination fish to fry.
| deathanatos wrote:
| And that timescale is called TAI. It's always been an option,
| but for whatever reason, people (and standards)
| (collectively) use UTC but want it to act like TAI.
| rightbyte wrote:
| Ok let future generations take the hit. Got ya. Selfish ...
| ender341341 wrote:
| How big of a hit is it on the future generation, they can
| just change their DST, which already happens every few
| years anyways?
| Stupulous wrote:
| The critical question is whether they'll have to leap
| forward or fall backward. We simply cannot abide stealing
| an hour of sleep from our cyborg/transhuman descendants.
| We'd never live it down.
| wmf wrote:
| When longtermism meets leap seconds.
| mark-r wrote:
| Hopefully by the time they need to make an hour's
| adjustment, we'll have done away with the anachronism
| that is DST. So then they'll have to learn to do it all
| over again from scratch.
| throw0101a wrote:
| > _at the current rate it 'll be ~9000ad before we hit an
| hour offset_
|
| And the leap year problems of the Julian calendar weren't a
| problem... until they were. And then good luck coordinating
| things:
|
| * https://en.wikipedia.org/wiki/Gregorian_calendar#Adoption_b
| y...
|
| * https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cal
| e...
| willis936 wrote:
| The thing is, we've remade calendars many times in the past
| millennium and our current calendar is not gospel. Sidereal
| drift can and should be addressed with a calendar fix, not
| a clock fix. The clock's a clock, the calendar's a
| calendar. It doesn't matter if we can make our clocks
| calendar-like because they shouldn't be anyway.
| [deleted]
| Stupulous wrote:
| The Julian Calendar was good enough for centuries after the
| empire that invented it had fallen, which I think counts as
| good enough in general. That said, I'd love to read a story
| about tracking down some time bug a million layers of
| abstraction down from the state of tech in 9000AD.
| LaputanMachine wrote:
| > we do hour offsets twice a year, so if an hour off is okay
| why is 1 second off not?
|
| The actual Unix time does not change when the clocks are
| switched between daylight saving time and standard time. Only
| the time zone changes.
|
| When a leap second occurs, the actual Unix time changes,
| which can lead to bugs, e.g. when a positive time difference
| comes back as negative. To prevent such issues, a monotonic
| clock can be used to measure time intervals.
| ender341341 wrote:
| Edit: OK, just re-read some docs, looks like POSIX chose
| the worst of all options and decrements the timestamp
| experiencing the same second twice...
|
| Wrong info from before edit: Unix time doesn't change
| either, it's the number of seconds since 00:00:00 UTC on 1
| January 1970, though systems may or may not ignore that and
| set it to match the UTC time.
| vlovich123 wrote:
| Yes. It does. Op is correct. A leap second specifically
| is an adjustment because "how many seconds since 1970"
| changes because the earth's rotation isn't constant
| speed. UTC tone definitely changes. If it didn't then you
| wouldn't hear anything about it and it would just be
| transparently folded into your time zone database.
| clysm wrote:
| The difference should be handled at the same layer as time
| zones, which is already a mess and is already well-suited to
| deal with this type of thing.
|
| I'd argue there should be no adjustment until it gets to be +-
| 15 minutes from UT1. And even then, NO clock skewing, just a
| time zone adjustment across the board.
| dangero wrote:
| Google does "leap smearing" which seems like the best human
| solution to this problem:
| https://googleblog.blogspot.com/2011/09/time-technology-and-...
|
| standardizing leap smearing algos and constants could work
|
| -Bottom layer is atomic clock seconds -We define targeted
| relationship between current UTC and atomic counter that will
| occur on a given day and time X -Time is interpolated to drift
| UTC into place by the given day and time X -Standards body can
| adjust time on some regular basis by its relationship to the
| atomic clock and publish the algo to convert from atomic to UTC
| bilsbie wrote:
| Can anyone explain what the alternative is? Surely we won't just
| get more and more out of synch with the earths orbit?
|
| Also why does it say the earth is slowing down but this year it
| sped up. Sounds quite impossible?
| Hamuko wrote:
| > _Surely we won't just get more and more out of synch with the
| earths orbit?_
|
| Why does being out of sync with the Earth's orbit matter?
| kangalioo wrote:
| Because humans use time as an indicator for day and night
| bobthepanda wrote:
| Also, historically, we did care about the equinoxes and
| solstices falling on specific days of the calendar.
|
| We may not care anymore, but emphasis on _may_.
| cesarb wrote:
| We already accept an error of half an hour (most timezone
| offsets are multiples of a whole hour) or more (many
| timezone boundaries are widened to align with state or
| country boundaries). A couple of minutes is nothing next to
| that, and if start getting too far, we can simply redefine
| the timezone offsets (which we already do twice a year in
| many places, and any device which might be moved across
| timezone boundaries already have to deal with that).
| Vvector wrote:
| And you can still use UTC as your indicator for day and
| night. In 100 years, it would only drift around 1 minute.
| Hamuko wrote:
| We don't really do that on a second accuracy though. We
| need to add a whole new day to the calendar every four
| years to make up the difference. Meanwhile we've added less
| than half a minute worth of leap seconds.
| basilgohar wrote:
| The slowdown is the long-term trend caused by drag of the
| Moon's gravity, but the speedups are sporadic and as a result
| of events such as massive earthquakes that cause the Earth's
| rotation to speed up as some significant mass falls further to
| the Earth's center. The conservation of angular momentum is the
| principle that leads to those brief speed ups, but they will
| not fully counteract the longterm drag caused by the Moon.
|
| Edit: TLDR; Local maxima vs. overall trend.
| canadiantim wrote:
| How does the world vote?
| jgrahamc wrote:
| Did you read TFA? It's literally the first line of the second
| paragraph.
|
| _The decision was made by representatives from governments
| worldwide at the General Conference on Weights and Measures
| (CGPM) outside Paris on 18 November._
| TEP_Kim_Il_Sung wrote:
| So not the world? Title is misleading.
| yamtaddle wrote:
| Nobody is confused by this, except those who are trying to
| be.
| TEP_Kim_Il_Sung wrote:
| I am not confused, nor trying to be. It is a factual
| statement.
| feet wrote:
| >representatives from governments worldwide
| ajkjk wrote:
| It's a totally valid synecdoche. "The world votes..."
| doesn't mean "every human on earth votes...", it means "a
| worldwide body votes...".
| orra wrote:
| Quite, although even "every human on earth votes" isn't
| the most literal interpretation: the planet becoming
| sentient and itself voting would be.
|
| Of course, that's an absurd interpretation.
| krick wrote:
| It is "a valid synecdoche" only as long as we accept that
| doublethink and newspeak are desirable. Sure, calling
| black -- "white", dictatorship -- "worldwide democracy"
| and so on... everyone will adjust. And by "will" I mean
| "already do and always did" -- there's nothing new about
| this, it's just the "truths" we are supposed to believe
| in are what changes over the centuries, not the way
| societies work. Perhaps it's even true that there is no
| other way (which doesn't make me like it any more).
|
| So it's totally true that no one is _actually_ mislead by
| this, but I absolutely understand those who try to
| pretend they are, and have a slight disdain for those who
| try to defend this bullshit.
| ajkjk wrote:
| I... uh... it's a normal phrase. Dunno know what to tell
| you. You're not gonna get a lot of takers on this being
| "bullshit". Feels like you're mad about something big and
| taking it out on random irrelevant things.
|
| There's maybe an argument to be made that using language
| which implies the legitimacy of organizations as
| presenting "all of us" is a sort of supremacist way to
| act, because it casually legitimizes whoever happens to
| be in power without questioning where they got that power
| or whether they earned or deserve it.
|
| But, like, it's a standards body. If the world didn't
| have one it would want to go and make one and then be
| back where we started. This isn't the interesting
| battlefield for that kind of point.
| echelon wrote:
| I would only want qualified people and not laymen voting on
| this. It's technical, not social. It has little bearing on
| anyone's lived experiences apart from scientists and
| engineers.
| cstejerean wrote:
| > The decision was made by representatives from governments
| worldwide at the General Conference on Weights and Measures
| (CGPM) outside Paris on 18 November
| jll29 wrote:
| There has been a proposal in the 1950s to the UN by a German
| mathematician to replace the current calendar by a decimal-based
| system, in which leap YEARS are not needed either: everything
| would be divisible by 100. I can't remember where I heard this
| from, but the anecdote goes he got a reply saying thanks for the
| proposal, but it is not feasible to introduce such a massive
| change globally, irrespective of the proposed improvements.
| zokier wrote:
| That is mixing up quite a few different things. World Calendar
| [1] was proposed in League of Nations/United Nations, but it
| was created by US person. There was slightly earlier proposal,
| International Fixed Calendar[2] from British person that also
| had some popularity. Neither of these were decimal calendars
| though, that is something from French revolution [3], and even
| they did not really manage to make it very decimal.
|
| Afaik the most vocal opposition to reforms came from the US
|
| [1] https://en.wikipedia.org/wiki/World_Calendar
|
| [2] https://en.wikipedia.org/wiki/International_Fixed_Calendar
|
| [3] https://en.wikipedia.org/wiki/French_Republican_calendar
| nousermane wrote:
| ...but UTC is still offset from TAI by 37 seconds. Any plans to
| do anything about that, I wonder?
| [deleted]
| nullc wrote:
| Once leap seconds actually stop TAI-UTC will presumably just
| have a constant offset. Constants are kind of irrelevant since
| they are very easy to deal with. Really no different than GPS
| time being exactly 19 seconds off TAI.
| ink_13 wrote:
| I've never really understood why smearing the leap second is such
| a big deal. Surely if you have software that is going to be
| sensitive to small variation in the clock over 24h, you're
| already not using wall time.
| TheArcane wrote:
| Now collectively do the same with daylight saving
| throw0101a wrote:
| > _How, and whether, to keep atomic time in sync with Earth 's
| rotation is still up for debate._
|
| [...]
|
| > _The CGPM -- which also oversees the international system of
| units (SI) -- has proposed that no leap second should be added
| for at least a century, allowing UT1 and UTC to slide out of sync
| by about 1 minute. But it plans to consult with other
| international organizations and decide by 2026 on what upper
| limit, if any, to put on how much they be allowed to diverge._
|
| So everything about this hasn't quite been sorted out yet.
|
| At some point there may need to be a reckoning like was done with
| the calendar:
|
| > _Second, in the years since the First Council of Nicaea in AD
| 325,[b] the excess leap days introduced by the Julian algorithm
| had caused the calendar to drift such that the (Northern) spring
| equinox was occurring well before its nominal 21 March date. This
| date was important to the Christian churches because it is
| fundamental to the calculation of the date of Easter. To
| reinstate the association, the reform advanced the date by 10
| days:[c] Thursday 4 October 1582 was followed by Friday 15
| October 1582.[3]_
|
| * https://en.wikipedia.org/wiki/Gregorian_calendar
|
| As annoying as handling a leap second could be, if it happens
| even somewhat regularly it can be testing more often. Deciding in
| the future to do a 'one-off' event may be more challenging from
| both a coordination point of view, as well as trying to handle a
| rare event correctly in (e.g.) code.
| wbl wrote:
| And we finished that transition in 1917. Time is hard.
| bewaretheirs wrote:
| The drift is sufficiently slow that you can fix it with a "leap
| hour" when needed -- perhaps once every five thousand years.
| This could be handled for civil/local time via an adjustment in
| the timezone definitions (something which happens a few times a
| year today), leaving the underlying UTC timebase unchanged.
| zokier wrote:
| The main difficulty is convincing Greenwich to not be utc+0
| anymore.
| gpvos wrote:
| Are we actually compensating for continental drift of the
| area around London already?
| throw0101a wrote:
| > _This could be handled for civil /local time via an
| adjustment in the timezone definitions (something which
| happens a few times a year today), leaving the underlying UTC
| timebase unchanged._
|
| Like I said: it could become a huge coordination problem.
|
| * https://en.wikipedia.org/wiki/Gregorian_calendar#Adoption_b
| y...
|
| * https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cal
| e...
| bewaretheirs wrote:
| it's really just a tzdata update for the vast majority of
| computer systems. That package updates several times a
| year. Get the revised rule in there a decade in advance and
| you're golden.
| throw0101a wrote:
| > _it 's really just a tzdata update for the vast
| majority of computer systems._
|
| I don't think you understand how the _tzdata_ works: the
| _tzdata_ folks only update the contents _after the civil
| authority for a region changes the law_.
|
| So _first_ you have to get all the law makers to update
| what the legal statues say and _then_ you "just" update
| the computer systems. The latter is the 'easy' part, it's
| the former that's the coordination problem.
|
| And as someone who was around for the 2005 DST change, I
| can say that may also be quite the coordination problem.
| (Though I think code has gotten much better since then.)
| bewaretheirs wrote:
| That's a feature, not a bug. UTC adjustments require
| world-wide coordination.
|
| Timezone adjustments do not. They are fundamentally a
| local matter, and just need to be communicated to the
| tireless maintainers of tzdata, and can happen
| incrementally any time an area feels local time is too
| far off solar time.
| Epa095 wrote:
| Let them handle it in the future when it becomes an
| issue, in roughly 500 years (that's when the lack of leap
| seconds will sum up to roughly 30 min). If they still
| care about having the sun above London at exactly 12 (or
| whenever it is in ut1) they can handle it.
| N19PEDL2 wrote:
| Then let's skip the leap hour too: just let UTC and UT1
| diverge up to 86400 seconds and compensate that by changing
| the time zones when needed. Then, when the drift reaches
| 86400 seconds, the clock times are aligned again. At this
| point we just need to re-align the dates too, and this can be
| done by skipping February 29 on a leap year (which should be
| quite easy to implement in software).
| lifthrasiir wrote:
| We have an implicit assumption for definitions of noon and
| midnight right now. I can't tell if that assumption will be
| there 1000 years later, but assuming that, UTC and UT1
| can't really differ by much more than several hours.
| willis936 wrote:
| This is the way.
| vlovich123 wrote:
| Is that practical? Drift is slow and takes 1 min per
| century. Let's say you can live with 10 minutes of drift.
| That leaves minutes [10-50] which is 4 centuries vs minutes
| [50-10] where it's fine which is 2 centuries.
|
| Also, if the problem were time zones, time zones already
| support non-whole hour shifts, so why not just apply the
| leap second into all time zones? The reason is that that
| isn't what a leap second is. It's kind of "how much time
| has elapsed since 1970 midnight" and that number is
| corrected for with leap seconds. Time zone offsets don't
| help you here.
| bewaretheirs wrote:
| We actually live with about +/- 15 minutes of drift (of
| local solar noon vs. 12:00 local mean time) over the
| course of a year. See
| https://en.wikipedia.org/wiki/Equation_of_time
|
| And timezones one hour wide impose about a +/- 30 minute
| fixed error (and sometimes larger) on top of that - the
| difference between local mean time and local civil time.
| kps wrote:
| The correct answer is obvious -- to stabilize the Earth's
| rotation -- but there are a few implementation details to work
| out.
| kibwen wrote:
| If we simply detonate the moon it would cease affecting the
| Earth's rotation, thus solving the problem.
| masklinn wrote:
| But wouldn't the rotational speed of the earth become more
| erratic?
| kibwen wrote:
| Indeed, but all life would be extinguished by the ensuing
| orbital bombardment, thus solving the problem.
| Akronymus wrote:
| Wouldn't work afaict. You'd have to get rid of the mass,
| not just explode it.
| ARandomerDude wrote:
| "Sir, are you suggesting that we blow up the moon?"
| jsymolon wrote:
| Nope, just explosive rapid deconstruction.
| JadeNB wrote:
| > Wouldn't work afaict. You'd have to get rid of the
| mass, not just explode it.
|
| I'm sure kibwen had in mind a Hollywood explosion,
| whereby a detonated object ceases to exist, rather than
| turning into many smaller objects.
| 4str0n0mer wrote:
| If you would detonate the moon, break it up into small
| pieces and smear them out over its orbit, tidal friction
| would cease. Tidal friction is a major component of the
| earth's rotation's slowdown.
| throw0101a wrote:
| > _If you would detonate the moon, break it up into small
| pieces_ [...]
|
| Close to the plot of a recent Stephenson sci-fi novel:
|
| * https://en.wikipedia.org/wiki/Seveneves
| mark-r wrote:
| I hated the fact that you had to get 9/10 through the
| book to find out how it derived its name. The number 7
| appears right at the start, but it's a misdirection.
| Mountain_Skies wrote:
| You've created the plot for 'Space: 2099'. Don't let
| Hollywood steal your idea.
| KyleBerezin wrote:
| It would certainly be easier than fixing all of the software
| nullc wrote:
| Hurrah!
|
| Each leap second event causes hundred of millions of dollars
| worth of disruption and that's not including the disruption
| created by leapseconds even when they're not happening (e.g. the
| frequent false leap seconds) or the mini-disaster we're sure to
| experience should there be a negative leap second (which we are
| still trending towards).
|
| The delays are unfortunate because it's harder to transition
| applications that need UT1 to use an offset from UTC when the
| available time sources are still unpredictably and unreliably
| leaping on you (since to apply a UT1 correction you need your UT1
| offset and your UTC source to agree if and how a leap second has
| been applied).
|
| From a practical perspective it would be better to immediately
| discontinue leaping, then UTC would immediately become a stable
| time that adjustments could be applied against for those few
| applications that need them. It would also save us from a
| negative leap second.
| techdragon wrote:
| Hot take...
|
| Storing anything as UTC was a mistake and we should be using TAI
| for all storage and computation, only transforming into more
| human friendly formats for display to end users. This never
| needed to be a problem except we decided to make it harder to use
| TAI than UTC and so everything got built up off the backs of
| legacy bios level hardware supported UTC style clock behaviour,
| when we should have been using TAI from the start. Yes I know it
| would have been harder, but we got off our collective asses and
| decided to fix our short sighted decision making for Y2K date
| storage, why not this... if it truly costs as much for everyone
| to endure a leap second why wasn't it just fixed from the bottom
| up and rebuilt correctly!
| red_trumpet wrote:
| > we should be using TAI for all [...] computation
|
| How do you add a full day, if you do not know whether a leap
| second occured or not?
| coenhyde wrote:
| You've made a very good point. All new software/systems I build
| will use TAI64. As an industry we should just push this move
| ourselves
| gpvos wrote:
| Libraries are already available. See
| https://cr.yp.to/time.html and the pages linked from there.
| spiderice wrote:
| What would using TAI solve exactly? I'm unfamiliar.
| smilekzs wrote:
| Datetime storage would consist of two explicit parts: one
| free from leap seconds (similar to the raw timestamp you get
| from a GPS receiver), and description of when leap seconds
| happen, so that you can transform the leap-second-free
| timestamp into UTC. Feels like a more robust way in principle
| to me.
| henrydark wrote:
| So like a CRDT for time
| gpvos wrote:
| CRDT = Conflict-free replicated data type,
| https://en.wikipedia.org/wiki/Conflict-
| free_replicated_data_...
| ender341341 wrote:
| TAI is monotonic clock, and isn't adjusted for solar time of
| day, it could be considered universal as TAI would be the
| same between any 2 points, but UTC is adjusted for earths
| rotation, so a theoretical mars UTC would end up out of sync
| with earth UTC.
|
| EDIT: info below is incorrect about UTC not being monotonic,
| as pointed out in thread but is useful for monotonic vs non-
| monotonic:
|
| In UTC you can jump forward or back, so it's possible to do
| an operation after another operation but have a timestamp
| before it, which is bad for many reasons, top being auditing.
|
| do operation one at T0 do operation two at T1 do operation
| three at T-1
|
| in TAI it would always be do operation one at T0 do operation
| two at T1 do operation three at T2
| pcthrowaway wrote:
| Link for anyone interested:
| https://en.wikipedia.org/wiki/International_Atomic_Time
|
| I'm not sure how this differs much in practice from UNIX
| time
| zokier wrote:
| I'm pretty sure UTC is monotonic too, its unix timestamps
| that really are the true mess
| Epa095 wrote:
| Yeah you are right, when a leap second is introduced it
| becomes 23:59:60 (monotonic) in utc, while with unix-time
| a normal way to handle it is to repeat 23:59:59 twice
| (non-monotonic).
| Strom wrote:
| Leap seconds can be negative.
| toast0 wrote:
| A negative leap second means that 23:59:59 is skipped,
| you go from 23:59:58 to 00:00:00, which is monotonically
| increasing, in both UTC and unixtime.
|
| Positive leap seconds are monotonically increasing in
| UTC, where you get 23:59:60 between 23:59:59 and
| 00:00:00, but not in typical implementations of unix time
| where 23:59:59 repeats, and with milliseconds you go
| (breifly) 58.999 -> 59.0 -> 59.999 -> 59.0 -> 59.999 ->
| 0.0
|
| If you're only counting seconds, then both UTC and
| unixtime are always monotonically increasing.
| [deleted]
| brazzy wrote:
| Wrong. The very topic of this discussion, leap seconds,
| are non-monotonic adjustments to UTC.
| deathanatos wrote:
| UTC is monotonic, even during leap seconds. (A positive
| leap second adds a 23:59:60; no timestamp ever repeats,
| the clock never moves backwards.)
|
| (Negative leap seconds are similar, and do not affect the
| monotonic property.)
|
| POSIX/Unix timestamps, however, are non-monotonic. But
| that's a different timescale.
| zokier wrote:
| In what way are leap seconds non-monotonic in UTC?
| layer8 wrote:
| Arguably, being able to perform calendar calculations without
| leap-second information (which you don't have for the future)
| is more important in applications than maintaining to-the-
| second accuracy over calendrical timescales.
|
| What applications and date-time libraries should really do is
| differentiate between timestamps, calendar plus wall-clock
| time, and elapsed runtime. In most circumstances, only the
| latter would really need to be consistent with TAI.
| AnotherGoodName wrote:
| You don't have dst offsets for the future either. Those keep
| changing. That's not a blocker.
|
| The straight up truth is that we created something in
| between. Some parts of earth sun alignment are in the time
| zone abstraction layer and leap seconds are in the seconds
| count layer. There's no real cause for this and we should
| have moved to TAI to fix this blunder long ago.
| lifthrasiir wrote:
| I now realized that the parent meant everything should have
| been TAI from the beginning, which is indeed a valid take. We
| can't switch to TAI today only because we are already using
| UTC.
|
| Original comment: Only those who never tried to actually use
| TAI yourself can claim that you can use TAI instead of UTC
| without a problem.
| myself248 wrote:
| Just have 37 leap seconds to bring UTC into sync with TAI,
| then lock them together.
|
| That won't break anything...
| lifthrasiir wrote:
| Yes, that's what the CGPM eventually decided to do because
| they know UTC will have to stay.
| krick wrote:
| I'm not sure I support your "hot take" -- it is hot and
| requires a lot of contemplation. But that's not the point, IMO.
|
| The point is, that there ALREADY EXIST both TAI and UTC. TAI is
| true monotonic (whatever it means in a relativistic universe)
| and doesn't make any compromises. UTC abolishes monotonicity in
| order to keep both the length of a second and the time
| relationship to the orbital rotation. They both work. For
| whatever reason (for obvious reasons that is, but doesn't
| matter) UTC was chosen in virtually any software system to keep
| time.
|
| So, ok, if there is a suspicion of leap seconds being
| unnecessary. How about moving from UTC time to TAI then? Let's
| keep UTC as it is, keep adding leap seconds and just make it a
| best practice to rely on TAI for all datetime operations and
| world clock synchronization? Maybe it will work out, maybe it
| won't, but at least you won't be breaking a perfectly working
| alternative (currently -- mainstream) system.
|
| The more I think about it, the more outrageously stupid
| abolishing leap seconds seems.
| toast0 wrote:
| > For whatever reason (for obvious reasons that is, but
| doesn't matter) UTC was chosen in virtually any software
| system to keep time.
|
| What was chosen really isn't UTC. Several UTC seconds in the
| past are not accurately representable in unixtime. Several
| unixtime seconds in the past are ambigious as to which UTC
| second they are.
|
| Unixtime is awfully close to UTC time, but it's not the same.
| If UTC time stops inserting leap seconds and never has
| negative leap seconds, then they will be equivalent going
| forward.
| [deleted]
| krick wrote:
| Not really. I mean, it's true that we should distinguish
| between the 2 and everything that you said about the
| difference is also true. But unixtime doesn't really
| "exist" in a sense UTC and TAI do. It is rather an
| imperfect implementation of UTC, that chooses to ignore (or
| repeat) some seconds.
|
| You can hear that unixtime is the number of seconds passed
| since X. But it isn't really true though. The number of
| seconds is number of seconds, it isn't defined by our
| standards, it just exists. And TAI is a fair representation
| of how many seconds on Earth actually passed (on average)
| since whatever.
|
| UTC kinda does it as well by virtue of 1 second being equal
| to 1 TAI second, but it actually counts (counted until
| yesterday) the number of Earth's rotations. It's just every
| rotation (represented by 24H) sometimes consists of more
| than 86 400 seconds.
|
| Unixtime on each individual device counts nothing. It
| imperfectly represents UTC timestamp received over NTP.
| Some timestamps are represented twice by the same value. Of
| course, you can just put your device offline and call it
| "unixtime" whatever number of seconds it counts since any
| moment, but you know it will drift away from any meaningful
| "real" time soon enough.
|
| (Also, it's not even entirely fair to say, as you did, that
| it is unixtime that was chosen by all the software. Many
| programs store datetimes as strings. Usually, they still
| don't support "23:59:60" anyway, but that doesn't _really_
| make them unixtime. Unixtime is a timestamp encoding.)
|
| So, that's basically what I'm talking about: you can just
| make unixtime an implementation of TAI (as opposed to UTC).
| You can build a new calendar format for it, introduce a new
| name (not UTC!) for it and see how well it does when all
| the world slowly drift from Earth's rotation to keep up
| with TAI. Maybe it actually is fine, I'm not a judge for it
| (because it really is complicated and I didn't decide yet
| if it's a good solution or not). But why the fuck would you
| destroy UTC for it?! It is a closest usable representation
| of UT1, which doesn't stop to exist! Leave it be!
| naniwaduni wrote:
| Consider that the most widely deployed time standard outside
| the UT framework is GPS time, which was initially synced with
| UTC but is de facto TAI-19, because it turns out that
| constant-rate monotonic time is useful and UTC fails at even
| the alleged astronomical use-case.
| slavik81 wrote:
| If you want to keep UTC matching the solar rotation, why do
| you specifically require leap seconds? Why not leap minutes?
| Or leap milliseconds? The choice of +-1 s as the acceptable
| error seems arbitrary.
| lifthrasiir wrote:
| It is worthwhile to look at the past; before leap seconds
| the disagreement with UT1 was handled by changing the rate
| of UTC slightly, and that's probably even worse than leap
| seconds. And for a while the unit of adjustment was less
| than a second, varying from 0.05 to 0.2 seconds. I believe
| enough people have complained about subsecond adjustments,
| and thus leap seconds have survived only because not enough
| people have complained at that time.
| krick wrote:
| Because a minute is a huge amount of time (and, by the way,
| don't forget, that minutes don't exist, I just understand
| that you mean 60 seconds) and there is no such thing as
| "leap milliseconds" because UTC is literally just counting
| seconds. Basically, UT1 already is an implementation of
| what you call "leap milliseconds". Not literally, but
| achieves the same thing. And it is way too complicated to
| use it in practice outside of astronomy-specific tasks.
|
| So, to sum it up:
|
| - TAI is a real thing, it has a concrete meaning, and it's
| "leap infinity".
|
| - UT1 is a real thing, but is unusable in practice, and you
| could think of it as "leap ms"
|
| - UTC until yesterday was a real thing, meaning time, which
| has seconds equal to TAI-seconds, but not drifting from UT1
| for more than 0.9 s. Since today it's broken and I'm not
| sure what it even means anymore -- I mean, not in practice,
| but "platonically".
|
| - Nobody just introduced a standard that would mean "time
| with seconds equal to TAI-seconds, but not drifting from
| UT1 for more than 59 s" yet. I guess you could be the one
| to do it, but I'm not sure it would get a wide adoption.
| eternityforest wrote:
| Why is UT1 unusable? Can we approximate it with something
| like a polynomial that gets updated periodically?
| dwheeler wrote:
| Eliminating leap seconds was only a half measure. They should
| have finished the job by adding rockets to the Earth to
| ensure that its rotation will stay at exactly 24 hours.
|
| If they weren't going to do that, then why eliminate leap
| seconds? Kicking the problem down the road doesn't really
| solve the problem, it just makes it worse later.
| varajelle wrote:
| > its rotation will stay at exactly 24 hours.
|
| The earth rotate around itself in 23 hours and 56 minutes
|
| https://en.m.wikipedia.org/wiki/Sidereal_time
| krick wrote:
| It rotates itself in 23 hours and 56 minutes _relative to
| the fixed stars_. It rotates itself in 24 hours _relative
| to the Sun_. It is Earth 's rotation relative to the Sun
| what people care about in most situations, because day
| and night depend on that, not on the position relative to
| some far-away stars.
| doctor_eval wrote:
| Surely it's all the test firings of Merlin and Raptor
| engines that's slowing the earth down in the first place? I
| mean first he screws up twitter, now it's time itself.
|
| (/s)
| benlivengood wrote:
| As spacecraft start making return trips to Earth we'll run into
| similar adjustment problems because TAI doesn't progress at the
| same rate at different altitudes and accelerations, so there'll
| need to be a re-sync at some point. Satellites already have a
| similar problem but can just use direct synchronization with
| Earth since it's so close. In theory spacecraft could do the
| same direct synchronization to Earth time, but e.g. a computer
| on the dark side of the moon would need additional relay(s) to
| stay in sync.
|
| I'm not sure why we don't define an intergalactic time standard
| and approximate that everywhere with NTP-like protocols; one
| monotonic clock at rest (with respect to CMBR) in free space.
| The second is weirdly defined/tracked in Earth's gravity well.
| worik wrote:
| > Storing anything as UTC was a mistake and we should be using
| TAI
|
| I had to look up TAI. I disagree. UTC exists for a reason. But
| I am here to tell a war story.
|
| Before I arrived on the scene a customer said they wanted local
| time in the reports. (As in Wall Clock Time).
|
| The Customer is Always Right. OK?
|
| So the times went into the database as wall clock time.
|
| The designers of the data schema made a simplifying decision to
| store everything as text.
|
| No time zone went into the text string that described the time.
| (?? I do not know why. So easy it would have been)
|
| I come along and have to code animations using that time series
| data.
|
| Very few problems...
|
| As you would expect there are a lot of other problems with that
| database.
| andy_ppp wrote:
| Great, now if we could also stop using GMT in the UK and stick to
| British summer time year round that would be great
| finnh wrote:
| > The CGPM -- which also oversees the international system of
| units (SI) -- has proposed that no leap second should be added
| for at least a century, allowing UT1 and UTC to slide out of sync
| by about 1 minute.
|
| So, in one century, we'll get 1 minute's worth of drift.
|
| Recall that we all share the same clock within timezones, and 1
| minute of drift between atomic & solar clocks is the equivalent
| of traveling 1/60th of your timezone's width to the east or west
| ... something many people do every day as part of their commute.
| _Everyone's_ clock deviates from their local solar noon, and
| _nobody cares_.
|
| Put another way: (at most) one north-south line in your timezone
| will have solar noon & clock noon line up. Over time the relative
| location of that line will move. Fine. Let's not screw with our
| clocks in an effort to keep the location of that line fixed.
| layer8 wrote:
| The problem is mostly (or so I've heard) that the drift is
| relevant for astronomical applications, and they rely on time
| dissemination which is done in UTC. If UTC decides to start
| deviating from TAI by dropping leap seconds, those applications
| will be in trouble. I'm sure that the problem is overblown, but
| this is the reasoning that was put forward in the past.
| myself248 wrote:
| But leap seconds hose up astronomical applications too. They
| all start with TAI and then apply corrections as needed.
| There are lots more corrections than leap seconds, but
| they're applied proportionally, not as leaps.
|
| Leap seconds are a solution in search of a problem.
| ronsor wrote:
| People who are using time for astronomical applications will
| simply have to track the offset if they need to. I'm not sure
| how that's much more problematic than the current situation.
| agrajag wrote:
| Agreed. _Someone_ has to deal with the drift between
| astronomical time and earth time, better the class of
| software that deals with space than every time critical
| system in the world.
| zokier wrote:
| And of course there are things like Spain being in utc+1
| despite sitting almost entirely west of Greenwich.
| xivzgrev wrote:
| whoopie. Can we get rid of daylight savings time? That one
| actually kills people
|
| https://www.newscientist.com/article/2344401-annual-us-clock....
___________________________________________________________________
(page generated 2022-11-18 23:00 UTC)