[HN Gopher] It's time to leave the leap second in the past
___________________________________________________________________
It's time to leave the leap second in the past
Author : mikece
Score : 285 points
Date : 2022-07-25 16:08 UTC (6 hours ago)
(HTM) web link (engineering.fb.com)
(TXT) w3m dump (engineering.fb.com)
| treesknees wrote:
| >remain at the current level of 27, which we believe will be
| enough for the next millennium.
|
| I would have loved to read more justification about _why_ Meta
| thinks we no longer need the leap second beyond calling it a
| community push. They did a great job of complaining about how
| hard it is to solve from a technical perspective, and then
| explained how they solved it. Is the only problem really that
| Meta doesn't know how to test a negative leap second?
| wutbrodo wrote:
| They explain this at the top of the article:
|
| > This periodic adjustment mainly benefits scientists and
| astronomers as it allows them to observe celestial bodies using
| UTC for most purposes. If there were no UTC correction, then
| adjustments would have to be made to the legacy equipment and
| software that synchronize to UTC for astronomical observations.
|
| > While the leap second might have been an acceptable solution
| in 1972, when it made both the scientific community and the
| telecom industry happy, these days UTC is equally bad for both
| digital applications and scientists, who often choose TAI or
| UT1 instead.
|
| The claim is that the benefits accrue primarily to a community
| whose relative importance is minuscule compared to the broader
| software world in 2022. The tradeoff was made in 1972, when
| astronomers etc represented a vastly larger proportion of
| software.
| wongarsu wrote:
| I can't imagine people who need accurate timekeeping (like
| scientists, astronomers and the telecom industry) preferring
| UTC over TAI. They do however prefer UTC over UT1. UTC was a
| reasonable compromise in the sense that it's almost TAI, but
| is close enough to UT1 that you can get all countries on
| board without much effort. Imagine getting the whole world on
| board to accept a mysterious device that counts electron
| transitions, without giving some kind of reassurance that it
| won't deviate in any relevant way from the timekeeping system
| they are used to.
| jrichardshaw wrote:
| Actual research astronomer here, and as a (radio) astronomer
| I would love to get rid of leap seconds. Assuming that UTC =
| UT1 (the time measure based on Earth rotation) is not
| accurate enough for most calculation such that you already
| need to use UT1 tables/forecasts and leap second tables in
| your ephemeris calculations so there isn't really much
| benefit in trying to keep UTC close to UT1. And the reality
| is that for us they actually make things worse: we stop data
| acquisition at the telescope over the leap second period
| because we timestamp our data in UTC dealing with the
| changing interval would be a pain.
|
| There are some good arguments for keeping leap seconds, but I
| don't think research astronomy is really one (it might be
| more useful for amateurs), particularly on ~100 year
| timescales where you don't expect things to slip that much. I
| think this sentiment is shared by most of my peers,
| particularly those who actually have to implement data
| acquisition and analysis pipelines!
| whimsicalism wrote:
| Why can't large tech companies that need synchronization
| similarly switch to an alternative time without leap seconds?
| seoaeu wrote:
| Because time in the real world uses leap seconds. The time
| businesses open and close. The times reported in news
| articles. And so on. What facebook wants is for all of them
| to stop using leap seconds so facebook's infrastructure is
| simpler
| umanwizard wrote:
| Times reported in newspapers are not granular enough that
| it's even possible to notice whether leap seconds are
| used.
| gowld wrote:
| It's not just Facebook. A large community doesn't want
| them.
|
| https://www.cl.cam.ac.uk/~mgk25/time/leap/
|
| Time in the real world can use leap hours, the next of
| which will be in approximately 3000 years.
| yebyen wrote:
| The article you linked seems to be arguing pretty
| strongly against leap hours. I'm not sure we could solve
| all those problems even in 3000 years. Can we compromise
| and use leap minutes? That way the problem is a bit more
| immediate, in 50 years we're sure to have solved it; or
| we'll all be dead and it will be on someone else!
| umanwizard wrote:
| Instead of leap hours we could just permanently abandon
| leap anything, and state that the offset between UTC and
| TAI is fixed at 27 seconds from now on, forever. Every
| few thousand years, when this new UTC has drifted enough
| from solar time on the prime meridian for people to start
| noticing and caring, countries can decide to simply
| change their offset from UTC, which will just be a normal
| update in the time zone database that doesn't need to be
| coordinated with anyone else, i.e. something that already
| happens quite regularly.
|
| This is all quite hypothetical as it's hard to predict
| whether anything like our current technological
| civilization will exist thousands of years from now, but
| even if it does, a simple mechanism exists to avoid
| problems (just have each jurisdiction change their local
| time when they decide they want to).
|
| I can't see any downsides for literally anyone from this
| proposal, other than the insignificant downside to the
| British that they will lose the prestige of being the
| place that global standard time is based on.
| bbarnett wrote:
| Worst part is, the arguments are a bit silly.
|
| Time may change forwards and backwards, because my computer
| clock may be fast or slow. The same logic to correct for
| leap seconds, can be used if my computer is 2 sec fast.
|
| And your code had better handle it, and the os, libraries,
| it really is only hard ), if you have to support 1000s of
| novice devs.
| shadowgovt wrote:
| And FWIW, every major company _does_ have to support a
| thousand novice devs, every year, over and over, forever.
|
| Honestly, this issue screams education problem. "Time is
| a mess" should be taught alongside buffer overflow
| attacks and networking theory (in fact, networking theory
| is a _great_ place to teach "time is a mess," because
| you can roll it in alongside ideas like "simultaneous
| action is a lie" and "clocks are always wrong anyway").
| adrian_b wrote:
| Because they are lazy and are not aware of the prior work.
|
| Already decades ago many have proposed to use only TAI
| internally in computers, instead of UTC, which is not a
| time.
|
| UTC should have always been used only to compute the local
| times, together with the time zones, only for human
| interfaces.
|
| There have been for decades libraries for using TAI instead
| of UTC, and even versions of Linux or *BSD kernels patched
| to do time keeping in TAI, not in UTC, eliminating all
| problems with the leap seconds.
|
| Unfortunately the use of TAI has remained a niche, but that
| was the right solution.
| treesknees wrote:
| I can see that, but I disagree that it's enough of an
| explanation. The blog specifically gives an example of the
| Earth's angular velocity changing with the melting of ice
| caps. They even threw in a cute animation of an ice skater to
| explain it. Last I checked, we're in the midsts of global
| climate change which is rapidly melting our ice and raising
| sea levels. I'm supposed to take Meta's word that we'll never
| need another leap second then? Why is that the case?
| Instinctually it makes sense to me to have a clock that
| follows the Earth's rotation. Why does Meta believe this is
| no longer the case? The only justification I saw was "it's
| hard" followed by their explanation of how they've solved it
| already. So what is the problem that's being solved by not
| counting leap seconds?
| shadowgovt wrote:
| So, time is a human construct and Earth doesn't care how we
| measure it.
|
| It's not that we'll never need another leap second; we
| could add ten, negative ten, or zero in the next 25 years
| and Earth won't care. Who will care are humans, who may get
| a bit annoyed when the sun starts setting in equatorial
| latitudes at 3PM.
| mjamesaustin wrote:
| Based upon the historical trajectory, it would take
| around 6,666 years for time to be offset by 1 hour.
| crote wrote:
| The thing is, similar reasoning can also be used to promote
| getting rid of leap years. Heck, maybe just switch to 12
| months of 30 days while we are at it.
|
| If you want to use real-world time, you have to make sure it
| stays in sync with the real world. Switching to something
| which is close-but-not-quite-correct will cause even more
| issues than we are currently having with leap seconds. Can't
| deal with that? Well, just use the Unix timestamp like the
| rest of us?
| btilly wrote:
| The issue is that all timekeeping is going to be an
| approximation of our messy Solar System. The only question
| is, "How accurate is accurate enough?"
|
| Currently our calendar goes off by one day in 3236 years.
| If the history is calendars is indicative, in about 10,000
| more years we may change our calendar. (Or, being multi-
| planetary by then, maybe we'll consider it a quaint relic
| of our origin.)
|
| Our clocks predict astronomical time of day to less than a
| minute for a human lifetime. And both DST and timezones
| demonstrate that we're happy to live with the clock and Sun
| disagreeing by an hour or more.
|
| My position is that both are currently good enough for the
| next couple of thousand years. And we can let our distant
| descendants sort it out when the time comes.
| ilammy wrote:
| > _(Or, being multi-planetary by then, maybe we 'll
| consider it a quaint relic of our origin.)_
|
| It's more likely that every planet will have its own
| calendar and you'd have to do the conversions and
| translations. That's what scientists do with Mars time.
| Thanks to relativity, time at point A is not the same as
| time at point B, and whether they stay in sync for you
| depends on _how_ you get from A to B.
| dylan604 wrote:
| Yeah, if it wasn't for that pesky requirement to keep in
| sync with the wall clock, my life would be so so so much
| easier not having to deal with drop frame timecode. The
| video industry isn't exactly small, and nobody has just up
| and decided "meh, it's too hard, so we're going to push the
| everyone else to do what we want". We all put on our big
| boy&girl pants and do the work.
| zerocrates wrote:
| Of course, drop-frame timecode itself imperfectly
| compensates for the fractional framerate, and also as a
| result of the math not really working out there isn't a
| drop-frame standard for 23.976 fps at all, so _sometimes_
| the industry just throws up its hands and says "meh,
| it's too hard."
| dylan604 wrote:
| It's not that they don't have DF for 23.976 because it's
| hard, they don't because it wasn't needed. A 23.976
| framerate was never broadcasted as it wasn't part of the
| NTSC standard. In fact, rarely did anyone actually edit
| at 23.976 unless it was going back to film. They cut the
| telecined film as 29.97 video with no regard to A-frames
| or any other methods that would enable the edit to
| cleanly go back to source frame rate. They so didn't care
| that some times the film cadence changes on every single
| edit. Why? Because nobody needed it nor could they
| possibly imagine the time of the internet and digital
| streaming that could do any frame rate to even bother
| wasting time trying to do it "right".
| zerocrates wrote:
| Well it _is_ in the standards now and you still see just
| non-drop timecode being used on it, with the resulting
| noticeable skew from wall time as the duration gets up
| there.
| dylan604 wrote:
| Again, it is _not_ a broadcast standard, at least in the
| US. Pretty sure it 's not in non-US markets either. Sure,
| it's a format that modern decoders and monitors can
| handle, but it's just not a format that people are
| concerned about it matching wall clock.
| zerocrates wrote:
| 23.976 is in ATSC I'm pretty sure, but I take your point
| that in practice it's not used for broadcast.
| makeitdouble wrote:
| The video and music industry has been screwing a lot of
| our digital lives with mandatory encryption and anti
| hacking/reverse engineering requirements just to sustain
| some of their business models. The abstraction layer is
| different than this, but god the irony.
| ForHackernews wrote:
| I'd wager Facebook will not survive the next 50 years, so they
| probably don't need to worry about the next millennium.
| klyrs wrote:
| Weird, I came to a different conclusion after reading the
| article. There's already a graceful solution to non-monotonic
| time, which mitigates most of the problems: smear, don't leap.
| Only, it's not a universal solution, so various systems are out
| of sync during the smear. Solution: petition for a standardized
| smearing strategy. But yeah, leave "leap" seconds in the past.
|
| And, maybe, don't run sub-second benchmarks with a wallclock.
| daine wrote:
| If smearing were adopted as standard, the "seconds," "minutes,"
| and "hours" appearing in timestamps would no longer correspond
| to literal seconds minutes, and hours of duration, even in
| principle. That seems very misleading and bad.
| ncmncm wrote:
| Smearing is absolutely the worst of all possible choices.
| Instead of one second, you are out of sync with the whole world
| for all of 24 hours. And you are fooling with things for the
| whole period.
|
| _Of course_ it was Google who picked the worst of all possible
| choices.
| joshuamorton wrote:
| But, its practical success does in many ways prove that mild
| inconsistencies between different time systems are...fine,
| and so a leap-less approach wouldn't cause any issues.
| [deleted]
| Matthias247 wrote:
| > As already mentioned, the smearing is a very sensitive moment.
| If the NTP server is restarted during this period, we will likely
| end up with either "old" or "new" time, which may propagate to
| the clients and lead to an outage.
|
| That seems to be a solvable engineering problem. One could make
| sure the server is up to date on all recent information before
| taking it back into service. It's a similar problem as making
| sure that cache servers that have invalidated data don't go back
| into service before their cache is updated - which is tablestakes
| for services like CDNs.
|
| I guess the problem here are public servers that can't run
| software that understands doing that? I see the challenge for
| those, but maybe something like an improved version of NTP could
| fix it?
| danielovichdk wrote:
| "God" how I hate to work with time when programming. It's more
| difficult than pretty much everything else.
|
| Cache invalidation and naming does not come close imo.
| neuronexmachina wrote:
| This article mentions some of the others who are part of the
| effort: https://www.cnet.com/tech/computing/tech-giants-try-
| banishin...
|
| > Google, Microsoft, Meta and Amazon launched a public effort
| Monday to scrap the leap second, an occasional extra tick that
| keeps clocks in sync with the Earth's actual rotation. US and
| French timekeeping authorities concur.
|
| > ... The tech giants and two key agencies agree that it's time
| to ditch the leap second. Those are the US National Institute of
| Standards and Technology (NIST) and its French equivalent, the
| Bureau International de Poids et Mesures (BIPM).
| tene wrote:
| If they don't want to bother with leap seconds, why are they even
| using UTC? Why can't they just use TAI instead?
| Balgair wrote:
| >Leap second events have caused issues across the industry and
| continue to present many risks. As an industry, we bump into
| problems whenever a leap second is introduced. And because it's
| such a rare event, it devastates the community every time it
| happens. With a growing demand for clock precision across all
| industries, the leap second is now causing more damage than good,
| resulting in disturbances and outages.
|
| Translation: We suck at computers and think you all do too. So
| let's just bury our head in the sand and make some cash before it
| all falls down.
|
| I'm being glib, but come on guys. You're trying to tell me that
| your crummy programming and cash flow is more important than the
| literal spinning of the Earth.
|
| You can try all you want, but the sun will set when it does, your
| clock be damned.
|
| I may be a rare person on HN that actually has dealt with these
| leaps from the 'source'. I used to work for a pico-second
| accurate timing company and had to go through the microsecond
| adjustment due to the March 11th, 2011 earthquake in Japan. The
| company was a backup site for the NIST clocks. I've even worked
| with _the_ second at NIST. Yes, that little port at about eye
| level that the whole US uses as it 's second. You can't take
| things out of the room (like asbestos) and you can only be in
| there for short periods, it's that sensitive and important.
|
| All that said, the Earth is a really crummy clock! But guess
| what? You can't fix that. It's mother nature's world and we just
| live on it.
|
| If FB thinks that trying to get everyone to quite literally 'not
| look up' is going to work in the long term, they are in for even
| more headaches than they already have. Many, many industries and
| sectors must use hyper precise clocks and they must be aligned
| with the Earth's rotation. If are not, then they will drift
| psuedo-randomly apart as all clocks do. And then you're screwed
| when you try to get your own little clock system to talk to other
| clock systems that have been drifting too. You think you have
| issues now with imagined negative leap seconds? Wait until you
| try to define time.
| Ericson2314 wrote:
| It's not just "legacy astronomical equipment". Humans like me
| want solar time = UTC + x for sake of e.g. scheduling meetings
| across time zones.
|
| It's embarrassing they can't figure out how to use the well
| accepted monotonic time solutions and are pulling this shit
| instead. Simple embarrassing.
| renewiltord wrote:
| Is there a single change that can ever be proposed that would be
| considered worth it? I can only conclude that status quo bias is
| very strong among people. With this in mind, I can only conclude
| that Mark Zuckerburg is some kind of organizational genius with
| both his "move fast and break things" and his "move fast with
| stable infra" lines.
| BrainVirus wrote:
| I have a solution that no one will like, but it's probably the
| least insane one in practice.
|
| 1. We move from using leap seconds to leap minutes.
|
| 2. We move leap minutes to timezone offset, because time zones
| are already a clusterfuck and you can't make them any worse
| anyway.
|
| 3. One-time adjustment to all timezones to get the system
| started.
|
| Result: Z timezone is equivalent to TAI. When you want to account
| for planet-related BS, you apply a timezone offset.
|
| You can definitely criticize this, but with a caveat: if you
| believe that Unix timestamp doesn't have leap seconds or that
| timezones only come in 1-hour increments you clearly have no idea
| how computer time really works and should probably read up on
| that first.
| lovecg wrote:
| But why do we need leap anything at all? Leap years are useful
| because the calendar drifts quickly (well, over centuries)
| enough for seasons shifting to become noticeable. Leap seconds
| correct for a problem that's much slower, with already existing
| much larger errors (time zones anyone?). It's a science project
| with no useful application in the real world.
| layer8 wrote:
| It would probably even be okay to make the corrections only in
| whole-hour or half-hour steps, to avoid odd timezone offsets.
| The Brits however won't like losing the 0-offset GMT.
| lucb1e wrote:
| Maybe it's more acceptable if the public is told they're
| likely to get it back at some undefined time in the future.
| (Or is that too soon after they severed EU relations only to
| immediately try and get those relations back in order?)
| gowld wrote:
| > if you believe that Unix timestamp doesn't have leap seconds
|
| If you have a source for leap seconds in Unix timestamp, please
| post a correction to Wikipedia.
|
| https://en.wikipedia.org/wiki/Unix_time
|
| UTC has leap seconds, and so Unix time can be converted to UTC,
| for the era in which UTC-with-leap-seconds is defined (after
| ~1972)
| [deleted]
| j0057 wrote:
| Can we not just fix our systems to run in TAI or GPS time, and
| convert to UTC (or the user's local timezone) when displaying
| timestamps, instead of causing civil time to drift off
| indefinitely? I thought these were the best engineers in the
| world, go fix the computers then!
| SoftTalker wrote:
| This is the answer.
|
| Humans want noon to be when the sun is overhead, and midnight
| to be the middle of the night. Almost nobody cares about sub-
| second accuracy or monotonic time. Track it that way internally
| if you like, but humans want time to correlate to what they see
| out the window.
| Ekaros wrote:
| It seems there is increasing amount of people who actually
| want the sun be overhead at 13 and midnight to be at 1... Or
| even later...
|
| So, if we stop actually caring about normal time, why should
| we care about leap seconds either...
| ncmncm wrote:
| That is what everybody ends up doing, in practice.
|
| It is exactly the problem. Why should every software system
| everywhere have its own complicated, unpredictable, error-prone
| fudge that benefits literally nobody?
| aubergene wrote:
| Whoever made that first line chart should have used step
| interpolation. There is no point in time when none integer
| amounts of seconds have been added, but it gives the impression
| it's been smeared over the whole year
| throw0101a wrote:
| Should we also get rid of leap years because programmers
| regularly screw those up? :)
| lucb1e wrote:
| Alternative solution: get rid of the programmers so you can
| have leap years
| eftychis wrote:
| It took Facebook/Meta only like ~20 years to figure out they
| shouldn't rely on time to keep things in sync? /s If you delve in
| distributed systems, I would be surprised if you never had the
| case of "hey 1/k of our computers think they are 1-2 hours behind
| in time. (because of NTP issues)"
|
| You could simply be working on a single computer and have to deal
| with time issues. (E.g. Local clock resetting to a prior date and
| system creating files timestamped earlier than older files.)
|
| I think the leap second is the most minor, not even worth
| mentioning problem. It is actually to our benefit, reminding us
| that ( _perceived_ ) UTC is not a monotonic measure and computer
| time altogether is not. Computers nowadays adjust their time
| ~constantly.
|
| That they have to smear their leap second throughout multiple
| hours, and that computers having the wrong time leads to an
| outage (for a less than a second difference) troubles me
| honestly. What you are telling me is that next leap second we
| should all pray for Meta's NTP servers not going down???
|
| Also: (if you are an fb engineer) What do you do with negative
| leap seconds? Speed things up...?
| (https://www.timeanddate.com/time/negative-leap-second.html) The
| expectation is for a negative leap second coming up -- as the
| post does mention.
|
| This is an education problem if you expect that time intervals
| have to be strictly positive (or jump ahead). TL;DR: systems'
| should never use the wall clock to compute a time interval even
| if we get rid of leap seconds.
| gmiller123456 wrote:
| For systems that leap seconds actually cause problems on, the
| solution is simply to use International Atomic Time (TAI)
| internally, and convert it to UTC when you want to display
| information to a user.
|
| Every time I see ditching leap seconds come up, they never try to
| explain why TAI won't work for them, leading me to believe they
| probably just don't know it exists, nor could they even imagine
| something like it being invented.
| sunshi23 wrote:
| I need someone to explain to me why International Atomic Time =
| TAI but not IAT
| gmiller123456 wrote:
| The actual name is French: temps atomique international. I
| guess we're lucky at least all of the first letters are the
| same.
| layer8 wrote:
| For a similar reason why Universal Coordinated Time = UTC.
| NovemberWhiskey wrote:
| That one's even odder - that's the compromise between the
| English version, which would be CUT and the French version
| which would be TUC ... i.e. none of the above.
| emmelaich wrote:
| CUT and TUC are probably naughty words in some language.
| CUT is close the the Dutch _kut_.
| layer8 wrote:
| TUC is a brand of crackers well-known in France, so maybe
| that's why they didn't insist on the French version. And
| CUT obviously didn't make the cut. ;)
| quesera wrote:
| My favorite example:
|
| The same reason that KFC (Kentucky Fried Chicken) is PFK in
| Quebec... In French: _Poulet Frit Kentucky_.
|
| Honestly, it feels more natural for adjectives to follow the
| noun. I think about this a lot when naming variables.
|
| English is a quirky language.
| cwp wrote:
| The problem with English is that you have to plan out the
| whole noun phrase in your head before you start talking.
| Not only do the adjectives have to come first, they have to
| be in the right order. With Romance languages you can just
| say the noun and then keep tacking on adjectives as they
| occur to you.
| ask_b123 wrote:
| Similar reason as the International Organization for
| Standardization being _ISO_ and not iOS :)
|
| https://en.wikipedia.org/wiki/International_Organization_for.
| ..
| jefftk wrote:
| I've heard quite a lot of Americans calling it the
| International Standards Organization
| jmole wrote:
| The same reason the International System of units is referred
| to as SI, and not IS: the French.
| jmole wrote:
| Seriously, I was reading this article wondering the same thing.
|
| Nanoseconds since X is a fairly unambiguous reference
| (relativity aside).
|
| Use this for any kind of timestamp or recordkeeping. Convert to
| UTC (or EST, CST, etc.) as necessary for reference to the solar
| day.
|
| The only reason not to do this is because you have a million
| systems that are already running on UTC, and you don't want to
| do a massive leap second erasure to get back to TAI.
| edent wrote:
| I can't quite reconcile the FB attitude of "we only hire the best
| and brightest after making them demonstrate their technical
| prowess" vs "computers are a bit hard please can everyone change
| everything to make it easier?"
|
| Why not just agitate for a move to French Revolutionary Decimal
| Time as well?
| alecbz wrote:
| A pretty big part of being good at software is deciding if a
| problem is worth solving.
| dastbe wrote:
| This is not a case of "computers are a bit hard", it's a system
| that we've imposed upon ourselves that has been repeatedly
| demonstrated to be unsafe. because of this, we've ended up with
| many (many) solutions baked into software that attempt to
| abstract away the sharp edges of this problem from individual
| engineers, which leads to inconsistent assumptions about what
| you need to consider when writing code.
|
| even with the best and brightest engineers there is a non-
| trivial probability that someone will make an assumption that
| is invalid based on their understanding of what can happen (ex.
| leap seconds never go negative!) or the library their using
| (this ensures monotonic time!) that could lead to disastrous
| results. and especially at meta scale, that probability is no
| longer "will someone make this mistake in our code?" but is
| "how many times will people make this mistake in our code?", so
| systemic solutions that eliminate this as a class of problem an
| individual can create is something we should consider.
| tgv wrote:
| > could lead to disastrous results
|
| You mean some influencer's timeline could get messed up? The
| horror!
| dastbe wrote:
| whether you like it or not, people are using facebook (and
| google, and amazon, and so on) as critical infrastructure.
|
| there are also all the other companies out there who do not
| have the platform that meta has that can also hit the same
| issues. i'm sure some of them have products you wouldn't be
| so glib about.
| mrguyorama wrote:
| >whether you like it or not, people are using facebook
| (and google, and amazon, and so on) as critical
| infrastructure.
|
| Only facebook here is the one suggesting we should change
| things, so who is using facebook as critical infra and
| what is your definition of "critical" here.
| barnabee wrote:
| Let the infrastructure fail at the next leap second. If
| it's enough of a problem eventually everyone who can't
| cope will go out of business.
| [deleted]
| User23 wrote:
| Reddit was down for almost an hour!
| ble wrote:
| Is UTC as a system inherently unsafe or does it just expose
| unwary programmers to bugs, the vast majority of which are
| somewhere between benign and inconvenient in impact?
| ncmncm wrote:
| It generates gratuitous, totally unnecessary bugs with
| impact wholly unpredictable.
| russellbeattie wrote:
| My exact first thought as well, which I will readily admit
| comes mostly from my bottomless contempt for the company and
| its employees. The thing that really needs to be left in the
| past is Facebook.
| ncmncm wrote:
| Even Facebook can be right twice a day.
|
| This is one of those cases.
| dexwiz wrote:
| Fun thought, we have only ever had positive leap seconds so far,
| due to slowing of the Earth's rotation. However, we could have a
| negative leap second. The rotation has just been consistently
| slowing since we started caring. But it could speed up again the
| future. We can predict rotation speed to a certain degree, but
| not completely. That is why leap seconds are announced only a few
| months in advance, instead of years.
|
| https://www.timeanddate.com/time/negative-leap-second.html#:....
| kortex wrote:
| I don't think we will ever need a negative leap second. We can
| just wait longer until dispatching the next positive one. The
| only situation in which we'd need a negative leap second is if
| Earth's rotation were consistently speeding up over many years.
| But we can tolerate some wiggle room (as in, several seconds)
| between UTC and TAI (since it's not in lockstep anyway).
| adrian_b wrote:
| The problem is that there are hardware devices and software
| applications, which compute UT1 (the angle of the mean Sun)
| from UTC and from dUT1 (which are transmitted both on various
| communication channels, e.g. by radio stations) and all those
| expect that dUT1 is a number between 0 and 1 seconds.
|
| If dUT1 can become either negative or larger than 1, all such
| hardware and software must be reviewed and possibly upgraded,
| to no longer make assumptions about dUT1.
|
| Communication protocols may have to be changed, if there is
| no way to encode a negative dUT1.
| ncmncm wrote:
| No. Literally _no one_ uses UTC or leap seconds for that.
|
| The only people who need to pay attention to sun angle are
| astronomers, and they use their own system based on TAI.
|
| So you are arguing to continue rejiggering a complex and
| error-prone system that benefits _exactly nobody_.
| kortex wrote:
| > If dUT1 can become either negative or larger than 1,
|
| Negative values should already be accounted for, afaict.
|
| > UTC is maintained via leap seconds, such that DUT1
| remains within the range -0.9 s < DUT1 < +0.9 s.
|
| I can't imagine why it would ever be constrained to
| abs(dut) < 1, as that does not appear to be a hard spec
| anywhere, it's just the goal. But I could see some really
| stupid implementations, so maybe.
|
| https://en.m.wikipedia.org/wiki/DUT1
| dexwiz wrote:
| UTC and TAI are already over 30 seconds apart. So not using a
| negative leap second to keep them aligned isn't really a
| valid argument. On a geological scale, Earth's rotation is
| slowing down, but on a decade scale, it's still pretty
| chaotic. We could just as easily be having the reverse
| conversation. When we need a negative leap second, we may
| need a few in a row. So just waiting for a positive one to
| cancel them out doesn't really work. Using the logic of it
| will all eventually be a wash and we shouldn't use them at
| all is kind of the argument the article is making.
| jefftk wrote:
| Everyone is treating this as some idiosyncratic proposal of
| Facebook's, but removing leap seconds is a mainstream position.
| Representatives of the US, China, France, and a majority of other
| countries were in favor of this when it was discussed at the 2015
| ITU meeting [1] though the UK and Russia's were not. This has
| been under discussion since at least the 2003 ITU meeting in
| Turin.
|
| [1] https://www.nature.com/articles/nature.2015.18855
| 0xCMP wrote:
| > "If we have an offset from solar time, it is not extremely
| important," [...] "We are already shifted by one hour in summer
| compared to winter time. Are we affected because of that?
|
| > Official time would slowly move out of sync with Earth's
| rotation, but -- given that it would take thousands of years to
| accumulate a difference that is greater than the kinds of
| shifts already caused by changing the clocks backwards and
| forwards for daylight savings time
|
| I think this argument: that we're syncing to atomic clocks and
| keeping in sync with the sun isn't so important should have
| been included in the post. I stand by my earlier comment that
| it felt like a hack, but aligning with SI unit of time + atomic
| clocks is, I think, far superior.
| yieldcrv wrote:
| Facebook should make another trade group so they can post well
| thought out proposals under that group's name without the ad
| hominem distractions of being Facebook
|
| Their name, Meta and Zuck's name is too sullied for good faith
| discussions
| ncmncm wrote:
| Yes. Leap seconds are just a thoroughly bad idea, from any
| angle.
|
| Yet, _not nearly_ so bad as Google 's approach: no leap, but a
| 24-hour smear, during which 24 hours they are out of sync with
| literally everybody else in the world.
| oittaa wrote:
| AWS does exactly the same.
|
| > The AWS Management Console and backend systems will NOT
| implement the leap second. Instead, we will spread the one
| extra second over a 24-hour period surrounding the leap
| second by making each second slightly longer.
|
| https://aws.amazon.com/blogs/aws/look-before-you-leap-the-
| co...
| ncmncm wrote:
| I.e., be out of sync all day long with literally everybody
| except Google.
| zsims wrote:
| At that point, how much of the internet is that?
| ncmncm wrote:
| Almost everybody.
|
| AWS and Google would like to think the internet is just
| them, but they are a tiny little bit of it.
| nvr219 wrote:
| No, you don't understand, Amazon and Google will be
| right, and everyone else will be out of sync with THEM.
| [deleted]
| mattnewton wrote:
| Didn't Google change their smear to 24 hours because it was
| what AWS and some other internet time servers used?
| ncmncm wrote:
| Yes: which shows that the skew was a problem.
|
| Eliminate UTC leap seconds, and the overwhelmingly worse
| smear problem vanishes too.
| joerichey wrote:
| For future leap seconds, Google (including GCP) are planning
| to use a "standard" smear
| (https://developers.google.com/time/smear). This is also the
| same smear used by AWS.
|
| It seems like if the ITU decides to keep the leap second (a
| bad idea, in my opinion), the large infrastructure providers
| will just use the same standard smear for their clocks.
| ncmncm wrote:
| They will be wrong all day long, not just for one second.
| AWS will be, too, evidently.
|
| Few others will do anything so idiotic.
| staticassertion wrote:
| What are the practical issues with potentially being
| wrong for one day by at most one second?
| a9h74j wrote:
| I assume finance and control systems to start. I might be
| helpful to have a fallback time-ordering algorithm not
| dependent upon one monotonic clock, but then you might
| have a rarely-used fallback to have bugs in, I imagine.
| guipsp wrote:
| They will be wrong by at most one second. And being wrong
| doesn't even matter, as long as everyone (or rather, all
| your servers) agree.
| fanf2 wrote:
| At most half a second, in the middle of the smear at
| midnight when the leap second is applied.
|
| The Facebook smear is asymmetrical so it starts off 1
| second off just after the leap second, and subsequently
| corrects itself.
|
| [ The reason Google and Amazon use a linear smear is
| because NTP clients try to measure the rate difference
| between their local clock and the reference clocks; if
| that is different every time the NTP client queries its
| servers, it will have trouble locking on and accurately
| matching the smear curve. You can mitigate this somewhat
| by fixing a higher NTP query frequency, but that's a
| heavy-handed fix for an engineering mistake. ]
| stjohnswarts wrote:
| As someone who has had to deal with it in embedded, I'm all for
| removing it and finding a better way.
| 0xCMP wrote:
| Can't help but agree with 80% of this post but strongly disagree
| with the solution. This feels like a hack that punts the problems
| to the future.
|
| UTC has the leap second cause it's not "real time" and so now
| we're just gonna never sync up UTC to real time at all? How is
| that the solution? Either we deal with leap seconds or we need to
| implement something that can't go backwards and properly models
| time. Leap seconds seem much simpler...
|
| In the end we didn't get rid of SQL cause of SQL Injection. We
| fixed the frameworks and promoted the solutions. We may simply
| need to make a push for languages and etc to just properly
| support time and promote how to do things correctly. It honestly
| seems easier.
| afiori wrote:
| Just by virtue of living in very irregular timezone (with
| sometimes DST) wall clock time is often 2-3 hours off solar
| time.
|
| We could wait enough leap seconds to reach 30 minutes and then
| have a smaller (or bigger) DST timejump and nobody would
| notice.
| wyuenho wrote:
| > This feels like a hack that punts the problems to the future.
|
| We've already done this before, it's called the Gregorian
| Calendar.
| jasonwatkinspdx wrote:
| > we need to implement something that can't go backwards and
| properly models time
|
| There simply is no definition of solar time that can obey this
| constraint long term, because the rotation of the earth varies,
| and varies over time in ways we have a limited ability to
| predict. This is the entire crux of the problem.
| ncmncm wrote:
| It is not the crux of any problem, except for, uniquely,
| astronomers.
|
| But they have their own solution we need pay exactly zero
| attention to. Leap seconds in UTC are just as big a nuisance
| for them as for everyone else. They have TAI, sidereal time,
| and this dumb bastard UTC with its own hacked up thing that
| doesn't match their precise alternative.
| hannasanarion wrote:
| UTC with leap seconds already does this. Leap seconds don't go
| backwards, they just alter the number of seconds in a minute.
| When the leap second passes, you have a minute with either 59
| or 61 seconds in it.
|
| The problem described in the article where "time goes
| backwaards" only exist when you compare two different time
| sources, which is always risky, whether a leap second is
| happening or not.
| ncmncm wrote:
| False.
|
| UTC is a count of seconds. Conversion to HMS is dictated to
| fool with the S field, but everybody suffers. The seconds
| count is supposed to actually skip.
| fanf2 wrote:
| UTC is not a count of seconds, because the standard
| representation of UTC does not have enough information to
| give you the right count. You also need to know the leap
| second table to convert a pair of UTC times to an accurate
| interval.
| alerighi wrote:
| Because we are still correlating time with the rotation of the
| earth. Time is an absolute measure, a second is defined as a
| precise amount of time, and you can count the time that one
| event with that measure. Only historically the second was
| defined as a fraction of the day, and was correlated to the
| speed of the rotation of the earth, to this days we have better
| ways to define it.
|
| Who said that time needs to be in sync with rotation of the
| earth? Nobody, who cares? It's a so small variation happening
| in a so long period of time to not be noticeable to any
| practice use: it's not that we take the sun as a reference of
| time anymore! We can keep counting time as we want and not be
| bothered with something not precise as the rotation of the
| earth. And for the applications that require that sort of
| precision, and only them, adjust the time accordingly.
|
| I mean, a meter was once defined as the one ten-millionth of
| the distance from the equator to the North Pole along a great
| circle. It's not that for this reason if the distance between
| the North Pole and the equator changes we are all throwing away
| our meters... it's just that we found a more precise definition
| of one meter. Same happened with the second (and all the time
| measures, such as a day): we express them in a new format where
| it no longer matters what the earth and the sun do.
| ok_dad wrote:
| > Who said that time needs to be in sync with rotation of the
| earth? Nobody, who cares?
|
| Humans sleep, usually at night time, and the rotation of the
| Earth defines night in any location, so regardless of the
| continual tick of some sort of "universal clock" we need a
| way to measure daily events that humans can use that rely on
| the sun going up and down at certain times and thus we need
| to adjust our local Earth times based on it's rotation.
|
| Maybe we can decouple UTC (or whatever) from local times
| completely, so then a leap second is just a second we add to
| or remove from the offset for any given location, but we
| still need to deal with adjusting local clocks to the
| rotation of the Earth and it's orbit around our star, the
| "Sun".
| turminal wrote:
| > In the end we didn't get rid of SQL cause of SQL Injection.
| We fixed the frameworks and promoted the solutions.
|
| I mostly agree with you, but this is a bad example. SQL
| injection is sadly still very far from a solved problem.
| moron4hire wrote:
| No, SQL injection is a solved problem. There are just poorly
| trained/idiotic/lazy developers who don't use the solution.
| rwalle wrote:
| Nah. Show me evidence it is "solved".
| naikrovek wrote:
| you sound far too confident in that answer for it to be the
| actual correct answer.
| mrguyorama wrote:
| >you sound far too confident in that answer for it to be
| the actual correct answer.
|
| What kind of non-argument is that?
| 988747 wrote:
| Database drivers for mabny programming languages have
| something like Java's PreparedStatement which allows you
| to compile the SQL query together with code, before the
| application is ran. Whatever input is provided later by
| the user cannot result in SQL injection, because it is
| not parsed/compiled at all. So yes, SQL injection is a
| solved problem, it's up to you whether you know about/use
| the solution.
| im3w1l wrote:
| The issue is that the type system doesn't enforce that
| the query is a literal / bundled resource.
| tremon wrote:
| The SQL language is not flexible enough to allow
| preparation of every possible query, so the problem is
| fundamentally not solved. To take a simple example: query
| parameters are not supported in DDL or DCL statements,
| and in DML queries the usage of parameters is limited to
| values only: even such a simple thing as an ORDER BY
| clause cannot be controlled by parameter insertion.
|
| "We have solutions for the most common occurrences" is
| not the same as "the problem is solved".
| BiteCode_dev wrote:
| Depends if you define a solved problem as a problem with a
| known solution (theory) or as a problem people still pay
| the cost for in the wild (practice).
| mmmpop wrote:
| >> solved
|
| Oof classic 3rd rail for when you're arguing with CS
| grads
| ncmncm wrote:
| That is what makes it a good example: SQL injection is still
| a million problems that would need to be fixed in a million
| places, and _will never be_.
|
| Leap seconds are a nuisance and source of bugs in a million
| programs. Fix them here, fix them there, it will always be
| wrong in the majority.
| jjoonathan wrote:
| I'd argue that TAI has far more right to the term "real time"
| than UT1. The Earth's wobbling and halting deceleration should
| not impact, let alone underly, our definition of time. UTC
| agrees with this assessment almost always: it tracks TAI except
| for leap seconds that prevent it from de-syncing too far from
| UT1.
|
| TAI > UTC > UT1
|
| That said, the hard work to build out a compromise has already
| been done, so whatever, let's just keep it until political or
| speed-of-light issues make it awkward to distribute information
| about leap seconds, at which point dropping them will be an
| easy and natural solution.
| mrighele wrote:
| > The Earth's wobbling and halting deceleration should not
| impact, let alone underly, our definition of time
|
| If you define time in terms of days and years, I.e in term of
| revolutions of the earth around the sun and itself, of course
| it's wobbling and deceleration has an impact. If you think it
| shouldn't then measure time differently, for example as
| seconds since a certain instant
| mattnewton wrote:
| > If you think it shouldn't then measure time differently,
| for example as seconds since a certain instant
|
| Isn't that what the article is arguing we do? What
| practical benefit does keeping this historical definition
| of time give us? Outside of people trying to account for
| the rotation of the earth precisely who could even notice?
| pixl97 wrote:
| > The Earth's wobbling and halting deceleration should not
| impact, let alone underly, our definition of time.
|
| Who's definition... the whole relativeness of time means this
| is a problem.
|
| Yea, I agree that we should have a unit of time defined for
| things near sea level and not moving very fast. But even that
| becomes problematic over 'long' periods of time as the earth
| is slowing down and will skew from what humans experience, of
| which has been the basis of how we define time until
| recently.
|
| Even then we're still leaving out the problems of things in
| space and on other planets.
|
| At the end of the day we're attempting to define time as
| something exact for all observers, and when you attempt to
| give an exact definition to something that is not exact
| problems are going to occur.
| msla wrote:
| It's natural to distinguish between wallclock time and
| duration time; or, time used to fix events chronologically
| and time used to figure out how long to do something. The
| first kind of time is the only plausible use case for leap
| seconds, because if you insert a leap second into the
| command "run main motor three seconds" you're going to be
| in a lot of trouble.
| [deleted]
| 6gvONxR4sf7o wrote:
| In general, I hate when people doing people things gets replaced
| by bureaucracy doing bureaucracy things. Structure should support
| people, not the other way around. That includes time. If people
| want midnight (on their clocks) to match midnight (in their
| lives) or whatever, then the structure and code we put to it
| needs to support that. That includes changing things like time
| zones and calendars and leap years, and yes, leap seconds too.
|
| Just because we suck at codifying things doesn't mean we should
| change the goal to make it easier to codify. If you need a more
| straightforward clock in your software, use just TAI or
| something, instead of trying to redefine calendars.
| jefftk wrote:
| Midnight on your clock is very likely tens of minutes or even
| hours offset from solar midnight, let alone seconds:
| http://blog.poormansmath.net/images/SolarTimeVsStandardTimeV...
| NovemberWhiskey wrote:
| Next up from FB: about that whole "February has 29 days in a leap
| year" thing...
| notacoward wrote:
| FWIW, Facebook did _not_ use UTC when I was there. They used
| Pacific time everywhere, which was even worse. And half of the
| internal tools would convert to local time but the other half
| wouldn 't. I just kept my work machine in Pacific time even
| though I'm in Eastern, so that compiling incident timelines (for
| example) would be less tedious and error-prone.
| throwawaytime99 wrote:
| If utc is causing problems with your calculations due to leap
| seconds than you should be using Unix time to do the calculations
| and then translating that to a human readable format.
|
| Imo society needs three distinct time counting systems.
|
| 1. Linux time. Essentially a universal addressing system for the
| measure of time in a agreed upon reference point (Earth's
| surface). This should be the standard for science/computation,
| with the need for language to describe time dilation when
| comparing two reference points. Unix time doesn't have leap
| seconds, or the concept of days.
|
| 2. UTC aka civil time. Things such as the orbit of the sun and
| the rotation of the earth aren't in constant speed and don't
| divide evenly with each other. UTC deals with short term
| variability with leap days and leap seconds. This is so every
| January 6th the earth is roughly in the same spot relative to the
| sun, and every 5pm the earth is in roughly the same part of its
| rotation. This is important because these things drift on human
| scale timelines. This calendar should be used for daily life,
| business, etc.
|
| 3. A purely astronomic calendar. A calendar that defines time by
| astronomic events. For example, defining a day as one rotation of
| Earth and not as a number of times an atom vibrates. This should
| be used so we can discuss astronomical events such as "A Martian
| year" or a "Saturn Day" and provide some meaning. This is the
| basics that should be taught to elementary school children to
| establish the cultural meaning of a day or a year and to provide
| some basic learnings of nature.
| [deleted]
| BoppreH wrote:
| Unix time does have leap seconds. From Wikipedia:
| It is the number of seconds that have elapsed since the Unix
| epoch, excluding leap seconds.
|
| Yes, it means the Unix timestamp jumps around, either skipping
| or repeating a second, when there's a leap second. Yes, it is
| as stupid as it sounds.
| cpcallen wrote:
| I think this is the real problem.
|
| If we used a unix-time-including-leap-seconds instead then
| the date/time conversion functions would need to have a
| little extra smarts (a table of leap seconds in addition to a
| timezone database) but most of the leap second related
| problems would not exist.
|
| (We already deal just fine with months having variable
| numbers of days. Minutes having variable numbers of seconds
| is obviously awkwardly rare from a testing point of view, but
| not fundamentally more difficult to get correct.)
| dane-pgp wrote:
| > not fundamentally more difficult to get correct
|
| The fundamental difference is that we can predict well in
| advance how many days will be in a given month, and the
| rules for calculating that number can be implemented with a
| short lookup table and a few modulo operations.
|
| The lookup table for past leap seconds, however, is already
| longer than 12 entries, and there is no way of calculating
| the length of all future minutes.
|
| On the other hand, the problem may be simpler than keeping
| track of changes to timezone definitions, since there are
| hundreds of jurisdictions that can unilaterally change
| those.
| [deleted]
| shadowgovt wrote:
| So what's the alternative? The leap second is capturing an actual
| skew between uniformly-ticking clocks based off of atomic decay
| statistics and the rotation of planet Earth. Stop updating them,
| and we end up with the sun going down for equatorial latitudes at
| 3PM eventually.
|
| This feels very can-kicky, even if the can can be kicked a
| thousand years down the road. I don't think more can-kicking is
| really the best solution.
| wmf wrote:
| Once the discrepancy exceeds 30 minutes you change the time
| zone offset.
| shadowgovt wrote:
| So their complaint is that one-second skews happen
| infrequently enough that they are always a headache, and we
| want to "solve" the problem by... Replacing it with a _less_
| frequent time modification that introduces _larger_ delta?
|
| I've been on the front lines of adapting code for a novel
| timezone change. It _wasn 't_ pretty.
| ncmncm wrote:
| It is not, ever. Doing it every year or two imposes just as
| much disruption every year or two. A disruption once a
| century is at least 50 times less disruption.
| wmf wrote:
| Globally, time zone data changes all the time (more often
| than leap seconds) and thus software is better at dealing
| with it.
| [deleted]
| poppafuze wrote:
| Meta has it backwards, because they could've already made another
| choice. UTC is a representation of the offset. This will always
| need to be calculated somewhere. Much like how the GPS counts the
| time since the epoch and broadcasts the offset...it can be used
| or not by the user. Those times are a calibration adjustment. For
| UTC, that adjustment is a reference to the current status
| provided by IERS. That's literally the job of UTC.
|
| Meta can simply stop applying a time offset in their reference,
| use TAI for forensics, and then have a separately calculated time
| when they need to display in that representation.
|
| ...Which is what happens already. System time is seconds since
| The Unix Epoch. All of those times are calculated and available,
| and always will be. They chose one of them, didn't like it, and
| invented a crummy workaround. They could've logged it in TAI and
| appended the TAI TZ to all their timestamps.
|
| This is being done to work around poor coding choices they made,
| instead of making the computing fit reality. Basically "We chose
| smearing, which is a poopstain of tech debt, so we'll fix it by
| telling the whole world what time it is." That request is loaded
| with colossal hubris.
|
| They might as well have the second redefined. The real operators
| do their thing and leave the squawking to those who want to self-
| identify a poor coders. Because if they don't want to account for
| a clock that jumps, then they're kicking the can down the road
| and they want everyone else to join.
|
| Turning it into a Y2K or Y2038 problem is a sad choice of
| saddling bigger tech debt on the rest of the world.
|
| Calling it mainstream is as much of a narrative as permanent
| daylight savings time was. The software solutions exist and were
| deployed (at least throughout Linux and main userspace) by the
| June 2015 leap.
|
| This is a Facebook problem that they're sloppily handling by
| pushing it on literally everyone else.
| kstrauser wrote:
| Counterpoint: no.
|
| The hubris of "we'd rather not do this, so let's make the entire
| rest of the world deal with it instead" is impressive.
| dymk wrote:
| God forbid somebody suggest a solution to a problem.
| kergonath wrote:
| If the solution implies de-engineering society from first
| principles to satisfy a programmer's desire for regularity,
| it's more of a thought experiment than a solution.
|
| The world is messy, life is messy, and so is everything else.
| If that's too much for poor programmers, they need to find
| another job.
| barnabee wrote:
| Agreed. Honestly the only thing that article did is make me
| add "to irritate Facebook/Meta" to the list of reasons not
| to ditch leap seconds.
| kergonath wrote:
| > If the solution implies de-engineering society from first
| principles
|
| I obviously meant "re-engineering", but "de-engineering"
| works as well, in this case...
| kstrauser wrote:
| When the problem is "this is too hard for us (but apparently
| not our peers)", a valid solution is not "let's just ignore
| it, even though our idea would cause an enormous pain in the
| neck for the rest of the world".
| dymk wrote:
| Why do you think it's not also too hard for their peers?
| Any company with an interest in time keeping spends tons of
| money dealing with time zones and leap seconds.
| kstrauser wrote:
| Because I haven't seen the Google or Amazon proposal to
| ditch it. Perhaps they've written them and I don't know
| about them, but I'm not aware of them.
|
| We do lots of things that are hard because doing them
| right is often more important than doing them easily.
| Switching from ASCII from UTF-8 was a pain, but we did
| it. Software upgrades are a pain. Security infrastructure
| is a pain. Timezones are OMG such a pain. But in all
| those cases, we collectively said "welp, guess we've
| gotta do it".
|
| And what Facebook notably _didn't_ propose was a way to
| actually make this happen. Who's going to project manage
| the global coordinated effort to migrate the planet to
| Facebook Time? That sounds like much more work than them
| just fixing their time handling.
| jefftk wrote:
| It's not just Facebook: apparently in 2015 most countries
| wanted to drop leap seconds, though some wanted to keep
| them: _Most countries, including China, the United States
| and many in Europe, favour scrapping the leap second and
| basing UTC on the continuous tick of atomic clocks._ --
| https://www.nature.com/articles/nature.2015.18855
| Yujf wrote:
| Someone has to propose it first. Just shooting them for
| that seems bad.
|
| I agree that we don't just need to do something because
| fb wants to do it, but it might actually be worth having
| a discussion over.
| kstrauser wrote:
| OK, so I do agree with that. It's worth having a
| conversation about.
|
| But I don't feel like this rose to the level of an actual
| proposal. It was very short to assert a claim with such
| wide-reaching implications as "we should start ignoring
| leap seconds". As such, I don't think it calls for an in-
| depth rebuttal.
|
| Consider:
|
| Proposer: "It's time to leave Unicode in the past. It
| requires us to update every part of our system to deal
| with UTF-8 strings instead of much simpler ASCII, and
| we're spending a lot of resources. Because it's so hard
| and expensive, we should all use well-tested ASCII code.
| People who want to interoperate with our system can just
| rename themselves to use the Latin-1 alphabet."
|
| Everyone else: "No."
|
| Yes, it _is_ hard, and people have spent a lot of, ahem,
| time and money to figure out how to manage this at scale.
| But there _are_ real-world-tested approaches to dealing
| with the issue, and I firmly believe it's better to work
| out and coordinate on the remaining rough edges than to
| throw the whole thing away to make a handful of
| engineers' jobs easier.
| dymk wrote:
| It's not everyone else. Most countries want to get rid of
| the leap second.
|
| "A small number of countries however, including Russia
| and the United Kingdom, want to keep the leap second."
|
| https://www.nature.com/articles/nature.2015.18855
| ncmncm wrote:
| That is sufficient argument, alone, to drop it.
|
| UK used to decide on which date to switch to and from
| "summer time" every year. "The admiralty will take up the
| question in coming weeks."
| lelandbatey wrote:
| And god forbid we respond with _" that's not a good
| solution."_ To restate, here's the problem, quoted from the
| original article:
|
| > _" As an industry, we bump into problems whenever a leap
| second is introduced."_
|
| Their suggested solution is:
|
| > _" As engineers at Meta, we are supporting a larger
| community push to stop the future introduction of leap
| seconds and remain at the current level of 27, which we
| believe will be enough for the next millennium."_
|
| Most folks are rightly pointing out that there are many other
| solutions that we could introduce, which wouldn't have the
| downsides of UTC drifting away from our wall-clock time.
| Facebook didn't even discuss those solutions though.
|
| An example possible other solution: programmers (especially
| programmers at Facebook) should stop using UTC and should
| instead use TAI (which is literally UTC but without leap
| seconds). Indeed, using UTC time as anything other than a
| wallclock time should trend towards the norm. Even though
| this is a clear tru-ism, seeing it adopted would be way
| harder (due to language inertia and habits) compared with
| just changing the standard (nevermind that changing the
| standard would break a _ton_ of logic built around
| expectations like "midnight UTC falls on an integer multiple
| of 86400").
| ncmncm wrote:
| None of those are, in fact, any kind of solution. Most are
| strictly worse than status quo.
|
| The purpose here is for things to get _better_ , not worse.
| msbarnett wrote:
| What solution? Meta's entire proposal is "stop making the
| adjustment and let dealing with the accumulated error be some
| future person's problem".
|
| "Let's just kick the can down the road" isn't solving
| anything.
| dymk wrote:
| TFA explains that it largely doesn't matter if we just
| ignore the leap second. It's additional complexity to our
| timekeeping systems that doesn't buy us much (if any)
| value. All the super-precise systems which would be
| impacted by being one second off ignore leap seconds
| anyways.
| dmm wrote:
| Another solution would be to add an extra positive and negative
| leap second every year to make sure all those code paths are
| tested.
| throw0101a wrote:
| The FreeBSD folks run tests on positive and negative leap
| seconds to make sure things are fine:
|
| * https://lists.freebsd.org/pipermail/freebsd-
| stable/2020-Nove...
|
| Of course there's a whole lot of other userland code besides
| _ntpd_.
| ble wrote:
| It could be a holiday / hazing event for software engineers.
| ncmncm wrote:
| I.e., half of everything is broken each 6 months, instead of
| just every 15 - 30 months.
|
| Better would be half of everything _not_ breaking every 15 - 30
| months.
| fourthark wrote:
| Eventually we will have to get used to having two clocks, slowly
| diverging.
|
| It's inevitable because we don't want hours of slip on Earth and
| eventually we will move to other planets which certainly don't
| want Earth leap seconds.
| 1970-01-01 wrote:
| NASA has already started down this road!
|
| https://www.nasa.gov/mission_pages/tdm/clock/index.html
|
| https://www.jpl.nasa.gov/news/what-is-an-atomic-clock
| lavishlatern wrote:
| A lot of people in this thread are criticizing this move, but let
| me offer an opposite view.
|
| One of the largest electronic health records systems has code
| that predates the UNIX epoch. Much of the time handling code is
| custom written to deal with this. However, the code was so poorly
| written that the system would lose data during the double 1 am
| window that occurs during daylight savings time shift. Hospitals
| would just shut off all of their computers during this time to
| deal with it.
|
| As the article notes, issues with leap seconds have also brought
| down reddit and cloudflare. Many people in this thread are
| treating this like some sort of display of incompetence, but if
| you've ever written code that deeply interacts with time, you'd
| know how difficult it is to get right. A sign of a good system is
| one where it is difficult to fuck up.
|
| IMO it is better to guarantee that time always moves forward
| rather than trying to match computer time to human time.
| jeroenhd wrote:
| > However, the code was so poorly written that the system would
| lose data during the double 1 am window that occurs during
| daylight savings time shift. > [...] > Many people in this
| thread are treating this like some sort of display of
| incompetence, but if you've ever written code that deeply
| interacts with time, you'd know how difficult it is to get
| right.
|
| Your example only speaks for the incompetence argument.
|
| In reality, times and dates are really complicated. Luckily,
| the engineers at Facebook, Reddit, and Clouflare are being paid
| hundreds of thousands of dollars to show off their expertise.
| Is it that much to ask for them to read into details like leap
| seconds?
| lavishlatern wrote:
| It is too much. I was Google SRE and there is an internal
| meme showing a time series graph jumping backwards during the
| double 1am at DST. These mistakes happen everywhere and are
| best avoided by a system that doesn't allow them to happen in
| the first place.
| 1970-01-01 wrote:
| >IMO it is better to guarantee that time always moves forward
| rather than trying to match computer time to human time.
|
| Not sure if you're playing Cunningham's Law or if you don't
| know this was the line of thought until everything was so far
| out of touch with reality, 10 days of time never existed, and
| official records were kept with dual-dates.
|
| https://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates
|
| https://www.timeanddate.com/calendar/julian-gregorian-switch...
| mritun wrote:
| There's no need to redefine UTC. If you want a fixed monotonic
| reference clock you want TAI time (the atomic reference) not
| UTC.
|
| https://www.nist.gov/pml/time-and-frequency-division/nist-ti...
| lavishlatern wrote:
| I don't see how replacing all UTC in software with TAI is
| more realistic than breaking UTC sync with UT1 (isn't it
| literally doing the same thing?). The whole point is that
| going forward, leap seconds are going to get harder to deal
| with. Especially in the case of a negative leap second, which
| seems like a more "true" y2k-like scenario.
| Veserv wrote:
| The difference is that replacing usage of UTC with TAI is a
| voluntary choice made for each program, but redefining UTC
| to be a fixed offset relative to TAI, which is effectively
| just redefining UTC to be TAI, is a forced change on
| everything everywhere all at once that everybody has to
| handle because one of their dependencies changed.
|
| It would be like silently changing the start of unix epoch
| time to 1800 instead of adding a new "Unix time since 1800"
| and asking people to switch.
| lavishlatern wrote:
| Not at all. Everybody using UTC would just not need to
| deal with leap seconds anymore. A UTC second is the same
| as a TAI second. It's a no-op for the vast majority of
| UTC users. UTC will just drift slightly more from UT1.
|
| This change only affects people who need UTC to be close
| to UT1 and also somehow don't know what UT1 is.
| Veserv wrote:
| Sure, everybody using UTC when they actually want TAI
| would be a no-op, but then you irreversibly break
| everybody who actually wants UTC and assumed that UTC
| would not change meanings.
|
| The people who would be unaffected by the redefinition
| can already just trivially switch manually (as we already
| assumed that just redefining things under them would
| work), leaving the UTC people alone. There is no good
| reason to silently break all programs carefully designed
| to use UTC correctly to fix all of the programs
| haphazardly written by people who did not know what they
| were doing and used UTC when they actually wanted TAI.
| Especially since fixing the wrong use of UTC is so
| trivial that we assume it can be done with no
| modification.
| omoikane wrote:
| See also: https://developers.google.com/time/smear
|
| Which says both Google and Amazon smears over a 24 hour period
| (in contrast to Meta's 17 hour smear).
| ncmncm wrote:
| Worst of all possible choices.
| [deleted]
| sharikous wrote:
| A monotonic clock without leap seconds could be kept next to UTC,
| it can easily be standardized.
|
| The idea that this problem is so hard that users have to be
| inconvenienced to the point that reality is ignored is a bit
| strange to me.
| dexwiz wrote:
| This is literally what the TIA standard is. Anything that needs
| precise time already uses this standard.
| [deleted]
| adrian_b wrote:
| The problem is that UTC, despite its name, is not a time (it is
| an angle rounded to a multiple of 1/21600 right angles).
|
| Only TAI is a time.
|
| Already decades ago, some programmers have argued that
| internally all computers and their software should use only
| TAI, which is a time, so it behaves as expected, while UTC must
| be used exactly like the local times and the time zones, only
| at the interfaces with humans.
|
| If that proposal would have been adopted, there would not have
| been now any discussion about the leap second.
|
| The only reason for the existence of UTC is to keep dUT1, i.e.
| UT1 - UTC, under 1 second.
|
| If the leap second is eliminated, then dUT1 will grow over 1
| second, so there are other cohorts of hardware devices and
| software applications that must be updated in order to no
| longer rely on the assumption that dUT1 is less than 1 second.
|
| Anything that has any relationship with astronomy, e.g. for
| observations or for navigation, relies on computing UT1 (i.e.
| the angle between the mean Sun and Earth) from time, so it
| would have to be updated.
|
| Changing the definition of UTC would make it completely
| redundant, Instead of giving up to add leap seconds to UTC, it
| would be much better to make a final leap of a half of minute
| and have TAI = UTC after the date of the big leap.
|
| Having 2 identical times with an arbitrary offset between them
| would just add needless complications to all time-related
| software, forever.
| kortex wrote:
| > The problem is that UTC, despite its name, _is not a time_.
|
| Could you elaborate on what you mean? What is UTC if not a
| time? Like, datetimes vs time?
|
| Even if Unix time was based on TAI, you'd still need leap
| seconds in order to resolve the correct local time (which is
| based of even-minute offsets of UTC). Maybe it's easier to
| deal with in calculation post-hoc vs smearing on the day of,
| but that handful-of-accruing-seconds will always be there.
| nomdep wrote:
| Yes, but UTC could be just another timezone, and every
| timezone would be based on seconds offsets of TAI
| adrian_b wrote:
| UT1 is an angle, i.e. the longitude of the mean Sun
| projected on the Earth.
|
| The mean Sun is a fictitious Sun with a motion that is
| averaged in comparison to the real Sun.
|
| UTC is the UT1 angle rounded to a multiple of 1/21600 of a
| right angle, i.e. the angle corresponding to 1 second of
| time for something that completes a circle in 1 day.
|
| Because of this rounding, actually a truncation, UT1 = UTC
| + dUT1, where dUT1 is between 0 and 1 "seconds".
|
| Even if UT1, dUT1 and UTC are expressed in "seconds", these
| "seconds" are not the unit of time, but like I have said,
| such a "second" is 1/21600 of a right angle or pi/43200
| radian.
|
| Both UT1 and UTC are angles that approximate the longitude
| of the projection of the Sun on Earth, with various
| accuracies.
|
| Because the rotation of the Earth, which causes most of the
| apparent motion of the Sun, is almost uniform, the angle of
| rotation is almost proportional with the time, so the angle
| UTC is almost proportional with the time, i.e. with TAI.
|
| Because of the way how the "second" angle used for UT1/UTC
| is defined, the approximate proportionality becomes an
| approximate equality of TAI with UTC, but because the
| equality is only approximate, there is an increasing offset
| between them.
|
| In the ancient times, the people did not care much about
| time, but only about the angle of the Sun, which determined
| when it was light or dark, hot or cold, enabling or
| preventing various activities.
|
| In modern times with artificial lighting and heating and
| with many activities that proceed at predictable rates,
| time has become much more important than the angle of the
| Sun.
|
| In any case, in all contexts we must be aware that the
| angle of the Sun and the time are not the same thing, even
| if they are almost proportional, i.e. almost equal after a
| change of the measurement unit.
| kortex wrote:
| The rate of angular change divided by angle sure as heck
| sounds like units of time to me. The absolute angle
| isn't, but the rate of change is, and UTC still tracks
| with rate of change, with a phase angle we periodically
| twiddle.
|
| That's like saying a watch or even an atomic clock
| doesn't measure time, it measures oscillations. It's
| being pedantic to the point of obtuse.
| ncmncm wrote:
| Except, astronomers _do not use_ UTC now. So its sole
| supposed benefit completely misses the tiny slice of people
| it is supposed to be for.
|
| UTC has exactly one purpose: to be a common reference for
| everybody else. Making it not mess up everybody else, every
| year, is obviously the better choice.
|
| You may stop beating your spouse _now_ , and it will be
| purely an improvement.
|
| Having made the mistake 27 times already does not justify
| making it even a single occasion more, never mind forever.
| LeoPanthera wrote:
| It's frustrating that programmers want to redefine civil time
| just because it is "hard". This article glosses over the real
| world problems that detaching from UTC will cause.
|
| This article details some of the problems:
| https://www.ucolick.org/~sla/leapsecs/dutc.html
|
| (You may want to scroll down to "Implementing the plan outlined
| at Torino".)
|
| If we end leap seconds, it doesn't take long - only until 2028 -
| until "midnight" is sufficiently far from "the middle of the
| night" that you will have to consider the legal issues caused by
| events that happen just before or after 0000 hours.
|
| By 2055, the "minute" displayed on a clock may be incorrect,
| which again may cause issues with legal timestamps.
|
| And by 2083, sundials are measurably wrong.
|
| All because programmers wanted to save some lines of code.
| [deleted]
| bhk wrote:
| > This article details some of the problems:
| https://www.ucolick.org/~sla/leapsecs/dutc.html
|
| That article is ridiculous.
|
| * "Most telescope pointing systems fail" (by 2027) (with 5s
| deviation from earth rotation). Pointing systems cannot blindly
| rely on UTC anyway, since (a) even with leap seconds UTC is up
| to 1 second off earth's rotation, and (b) pointing a telescope
| depends on where the telescope is on earth, so some offset must
| be added to UTC by some human.
|
| * Hypothesized legal issues... give me a break.
|
| It would be much less trouble for humanity to deal with this
| once every 100 years or so.
| [deleted]
| BrainVirus wrote:
| _> All because programmers wanted to save some lines of code._
|
| No, it's because programmers don't want basic timekeeping in
| all devices involve the worst issues of managing a distributed
| system.
| ZetaZero wrote:
| > By 2055, the "minute" displayed on a clock may be incorrect,
| which again may cause issues with legal timestamps.
|
| I'm not following here. What defines "legal timestamps" in our
| current system? I'm unaware of any laws in the US that uses the
| actual position of the sun to determine the time.
|
| "Noon" when the sun is at the highest point, can vary over an
| hour across a timezone.
| lynguist wrote:
| A birthday is a legal timestamp. A car crash is a legal
| timestamp. When the time is off by a minute, these events
| can't be catalogued correctly any more.
| Ekaros wrote:
| Both can easily be placed on same monotonic time. Actually
| makes a things simple. You don't end up having
| 31/12/1972:23:59:60 and wondering why is there 60 there...
| PeterisP wrote:
| "off by a minute" from what exactly?
|
| Shifting the timezone by a couple seconds does not prevent
| or hinder cataloguing events in any way whatsoever,
| certainly not more than switching to daylight savings time
| does or the mere existence of timezones, which may easily
| be half an hour or even more off from the solar time - the
| offsets we use for time are effectively arbitrary already,
| and adjusting the arbitrary choice of the offset by some
| seconds is not a fundamental difference. Event timestamps
| already map to different days depending on different
| timezones, you do need to know which timezone your clock is
| using, of course, but you already need to do that.
| 0x0 wrote:
| For people born just around midnight, especially around
| new years eve, a few seconds could impact their DOB by a
| whole year. This could affect everything from university
| applications to boating licenses to social security.
| ncmncm wrote:
| It already does all that. Just unpredictably.
| joshuamorton wrote:
| Why does the position of the sun have any relation to the
| legal time?
|
| > This could affect everything from university
| applications to boating licenses to social security.
|
| Last time I looked, a boating license required you to be
| a certain age. Dec 31 and Jan 1 are still just as far
| apart as July 6 and July 7.
| cdash wrote:
| Maybe you seem to think that was is being asked for is to
| retroactively remove leap seconds from UTC? That is not the
| case, all that is being called for is to stop adding more
| leap seconds.
| DerpyBaby123 wrote:
| >"Noon" when the sun is at the highest point, can vary over
| an hour across a timezone.
|
| this is "solar noon" - just "noon" denotes 12:00 on the clock
| [1]
|
| [1]https://www.bsu.edu/academics/centersandinstitutes/ceres/h
| el...
| bonzini wrote:
| Way more than one hour. Even without taking China into
| account, A Coruna in Spain and Kosice in Slovakia are in the
| same time zone but they are 30 degrees (2 hours) apart.
| Ellipsis753 wrote:
| When the sun is directly overhead it's meant to be 12:00 - IN
| THEORY! However as Timezones are pretty wide, most of the time
| you'll be at least 15 minutes out. Sometimes you'll be out by
| as much as 3 hours - and you've probably never even noticed!
| Telescopes already have to compensate for this (as well as for
| summer time). Leap seconds make a shambles of book keeping too.
| What is "2022-07-17T12:00:00" + (60 x 60 x 24 x 365 x 5)
| seconds? No one knows! And the answer to that question will
| change depending on when you calculate it and which updates you
| installed! So I say ditch the leap second and let it drift. In
| a few hundred years we could update our timezones if we
| _really_ want to (timezone changing is actually pretty common,
| so code should already be handling this edge-case).
| DSMan195276 wrote:
| > If we end leap seconds, it doesn't take long - only until
| 2028 - until "midnight" is sufficiently far from "the middle of
| the night" that you will have to consider the legal issues
| caused by events that happen just before or after 0000 hours.
|
| I'm not sure what you're getting at here. If we stopped
| introducing leap seconds, then why would the legal world still
| care about them?
| whateveracct wrote:
| I'm assuming because timestamps exist to capture time in the
| real world
| alecbz wrote:
| What do you mean by "time in the real world"? The relative
| position of the sun to someone on Earth?
|
| _Some_ legal uses of time are probably concerned with this,
| but I'd think it's a pretty small minority.
| ncmncm wrote:
| Islamic time is, technically, but does not distinguish
| seconds. So, the only place where it _could_ matter, it
| doesn 't.
| jjoonathan wrote:
| I can believe that a desperate lawyer would argue the
| semantic distinction between clock-midnight and solar-
| midnight, but I have trouble believing that this would amount
| to anything more than one more dumb nit on a pile of dumb
| nits that the court has to deal with every day.
| Ekaros wrote:
| Also I think it would go through legal system in a few
| years and end decision is that clock-midnight is one that
| will be followed.
|
| Or even have legislation to agree on that and set single
| law.
| makeitdouble wrote:
| "civil time" is also a construction that is flexible in many
| ways, so an influencial group redefining it isn't out of norm.
| To note, timezones were introduced for railway purposes, and
| some country play a lot with them.
|
| For "midnight" being far from "the middle of the night", that's
| already a reality for many Chinese living far enough from
| Beijing, or god forbid regions where "night" doesn't mean much
| for half of the year.
|
| For all intents and purposes, if a formal definition of time
| isn't practical people come up with their own ways.
| Ekaros wrote:
| Midnight isn't midnight for absolute vast majority of people.
| Even with right sized timezones. That is one spreading from
| edge to edge...
|
| And then there is continental shifting... Which we also don't
| account for...
|
| A few seconds or few minutes really don't make that much
| difference for average person.
| jefftk wrote:
| Your article is from 2003 [1], so when they say "by 2028" they
| don't mean six years from now.
|
| Since the article was published we've gone from positive leap
| seconds every so often to looking like we may get the first
| ever negative leap second:
| https://upload.wikimedia.org/wikipedia/commons/f/fb/Leapseco...
|
| Which means the article's estimates on how long it will be
| until we're off by a given amount of time are very much
| obsolete.
|
| [1]
| https://web.archive.org/web/20030801000000*/https://www.ucol...
| amptorn wrote:
| I think that observation just lends further weight to the
| argument that the relationship between atomic time and
| universal time is a dynamic and unpredictable thing, which we
| need to handle correctly rather than pretending it doesn't
| exist.
| ncmncm wrote:
| That it is dynamic and unpredictable is _exactly_ why we
| should not force everybody to track it.
|
| Some people: astronomers and orbital mechanicos are obliged
| to care about sidereal time, regardless. Making me deal
| with it too is pure tax with exactly zero benefit.
| lucb1e wrote:
| > it doesn't take long - only until 2028 - until "midnight" is
| sufficiently far from "the middle of the night"
|
| Honestly from my perspective, 3am is the middle of the night
| (night-morning-afternoon-evening starts at 0-6-12-18 for me)
| and somewhere between 4 and 5 most people are probably asleep
| and the date change should occur. I can't count how often I've
| heard people clarify what 'tomorrow' means when the word is
| spoken after "midnight" but before going to sleep.
|
| But yeah gotta pick _something_ for the date change, it won 't
| be worth the cost of change now. If we do end up ever switching
| to something like decimal time, this should be on the todo list
| though.
|
| And I know "midnight" is historically supposed to be about the
| sun being the furthest from its zenith rather than in the
| middle between when you go to sleep and get up, however that
| occurs somewhere around 1am here (01:41 at its extreme, from
| July 17 till August 5th). If that's not enough to warrant a
| redefinition, 27 seconds accumulated since we started counting
| leap seconds are also not enough to warrant an update yet
| (following Facebook's logic here).
| philwelch wrote:
| From your link:
|
| > In about 600 years TI will be ahead of UT1 by half an hour,
| and in about 1000 years the difference will be a full hour.
|
| That's nothing. Time zones alone already create significantly
| larger errors. Belgrade and Sevilla share a time zone, but the
| solar meridian ("noon" on a sundial) is 12:44 in Belgrade and
| 14:30 in Sevilla. Obviously, the same error is present in the
| astronomical "middle of the night". This does not, in fact,
| create "legal issues" for Serbs or Spaniards.
|
| In 600-1000 years, around the time that it would actually
| matter, we're going to have to reform the time system anyway to
| account for relativistic drift between the surface of the Earth
| and human settlements elsewhere in the solar system.
| metacritic12 wrote:
| Isn't "cause issue with legal timestamps" just a circular
| definition?
|
| Sundials being "measurably" wrong become an issue at long
| spans. For example, no one wants solar noon to be at 10AM --
| but that takes a while.
| philwelch wrote:
| > For example, no one wants solar noon to be at 10AM -- but
| that takes a while.
|
| Solar noon in Spain is after 2PM already.
| 1970-01-01 wrote:
| >It's frustrating that programmers want to redefine civil time
| just because it is "hard". This article glosses over the real
| world problems that detaching from UTC will cause.
|
| Yes, the actual problem exists, and ignoring/discarding reality
| (i.e. the "science" in computer science) will just cause
| further problems. If you and your modern stack of code can't
| handle the leap second, it's simply not production code.
| alecbz wrote:
| > the actual problem exists
|
| I mean this is the whole contention. Meta's claiming this
| isn't actually a problem worth solving.
| ncmncm wrote:
| Moreso: it is not a problem that dealing with the nuisance
| that is leap seconds even solves. It is supposed to match
| civil time to astronomical time, but astronomers don't use
| it. It just makes things even more annoying for
| astronomers, and annoys everyone else, over and over again,
| for no benefit to anyone.
| prpl wrote:
| Please consider that none of this actually matters if we
| ditched UTC for TAI. For one, time zones still exist and local
| solar time is already decoupled from clock time.
|
| The worst case scenario is things are different.
| ncmncm wrote:
| Not everybody would "ditch UTC for TAI". Some would, some
| wouldn't. Now you cannot know whether you will match anyone.
| bartread wrote:
| > It's frustrating that programmers want to redefine civil time
| just because it is "hard". This article glosses over the real
| world problems that detaching from UTC will cause.
|
| I agree, but I'm also - sad to say - less than surprised to
| find engineers at a Big Tech firm taking a high-handed, not to
| mention narrow and ill-informed, approach over the issue and
| trying to impose their will on a global scale. My worry here is
| that, Meta being Meta, they carry quite a lot of influence and
| may actually gain some traction.
|
| EDIT: I'll add a bit more colour here. At the core of our
| platform we manage a database containing billions of legacy
| timestamped records (or events, if you prefer), adding more and
| more every day. Without even giving it a great deal of thought
| I guarantee you that this proposal will cause us more problems
| that it solves and will distract us from making more valuable
| investments of time and effort that would benefit our business
| should it be implemented. Sure, we can no doubt fix all these
| problems, but we've got better things to do. I imagine that
| many other businesses would be similarly affected and would
| take a similar view.
|
| I wholeheartedly oppose it.
| corrral wrote:
| I'm kinda impressed by the hubris, really. Usually it's
| emperors, kings, and big multinational governing bodies that
| try to screw around with the time standard that ordinary
| people have to live with. Occasionally strident
| revolutionaries who've already solved the "overthrow and
| replace the government" part of their problem and aren't
| content with just beheading people all day.
|
| Says something about how Facebook sees itself, I guess.
| ncmncm wrote:
| Facebook is arguing to _stop_ monkeying with the time
| Standard. Correctly.
|
| Leap seconds are exactly the "screwing around" you
| criticize.
| gnu8 wrote:
| That's all it is, they ran into an engineering problem and
| they're trying to get the world to bend to their will instead
| of solving the problem because they think it will be easier.
| Mark's arrogance is nauseating.
| easytiger wrote:
| Now expand this reasoning far beyond the scope of time
| keeping.
|
| Big Tech companies/Anti Big Tech lobbyists massively
| oversimplify in their pitch to influential people to
| deregulate/overregulate certain areas. In both cases they
| end up making poor decisions for the general case both end
| up making the average case worse for everyone except
| themselves. It's about creating a market where none need
| exist. Facebook doesn't need to care about time really.
| It's not remotely important to their business.
|
| I've built and worked on platforms with sub microsecond
| measuring requirements and this stuff didn't bother me.
| This is idle bad money finding work for itself at the
| expense of everyone else.
|
| Disclosure: I am/was an early investor in facebook in 2012.
| Mark is turning it all to dirt because he's run out of
| ideas
| jjoonathan wrote:
| > arrogance is nauseating
|
| Right back atcha.
|
| We have three alternative time systems and a big bag of
| issues with each of them, but you think the extremely
| mundane argument that we should prefer one bag represents
| nauseating arrogance because you think that your favorite
| bag -- a different one -- is obviously correct? Come on. Do
| better. Be civil.
| Veserv wrote:
| FB is not making the mundane argument that we should pick
| one time system over another. They are literally
| proposing that the world should redefine UTC to be TAI
| with a permanent fixed offset, which is functionally
| equivalent to just using TAI.
|
| That is effectively proposing the deletion of the most
| commonly used time system of the three primary time
| systems from existence and forcing everybody and all
| existing systems that use it to convert to what is
| effectively TAI.
|
| That is not mundane. Mundane is arguing that everybody
| should use TAI. Arrogant is arguing that we should force
| everyone to do it by redefining their dependencies under
| them.
| ncmncm wrote:
| That is the smallest change that eliminates all the pain.
|
| Arrogant is imposing a big nuisance on everyone every
| year or two. It is not arrogant to ask for a nuisance
| affecting millions to be dropped.
| Veserv wrote:
| No, it is a change that breaks everybody using UTC
| correctly, TAI with a offset to synchronize with UT1, in
| order to fix everybody who did not know what they were
| doing and used UTC when they actually wanted TAI.
|
| If there was a scheme that fixed only the wrong usages,
| that would be fine. But, it is frankly absurd that we
| should even consider breaking carefully designed programs
| correctly using their dependencies to fix programs
| incorrectly using their dependencies especially when it
| is trivial for the wrong usages to be fixed manually.
| ncmncm wrote:
| They will _still_ be using UTC. Just, without bugs that
| show up every year or two.
|
| Not announcing any more leap seconds will break exactly
| nothing.
| Veserv wrote:
| No, UTC is TAI kept in sync with UT1. Changing UTC to
| being TAI with a offset is a fundamental breaking change
| in what it means. Anybody relying on UTC doing what it is
| designed and advertised to do, keep in sync with UT1,
| will be broken. The only people who will not be broken
| are people using UTC incorrectly as TAI. The only reason
| this is interesting is that basically everybody uses UTC
| incorrectly as TAI, but that is not a valid excuse to
| break the programs using it correctly.
|
| People using the wrong dependency should fix their system
| to use the right dependency. They should not campaign to
| steal the name and replace it, that is absurd.
| ncmncm wrote:
| Literally nobody depends on any relationship between UTC
| and overhead sun angle.
|
| The only people who care or need to _do not use_ UTC.
| They use TAI, and a separate continuous log of fractional
| seconds.
|
| UTC has one role, and that is Standard worldwide civil
| time. Telling people who need Standard civil time to use
| TAI makes everything strictly worse: not only do you then
| not match most of the world, but you _still_ have to
| track irregular, unpredictable corrections to be able to
| sync with everybody else.
| zozbot234 wrote:
| There's no need to "detach" from UTC. Just ensure that TAI
| (which is consistently free of leap seconds) is also supported
| on an equal status to UTC, for applications where it makes the
| most sense. Conflating the two would only increase confusion
| further.
| LeoPanthera wrote:
| Programmers can _already_ do this if they want to. TAI
| already exists. But they 'd have to still display UTC as
| civil time to end users and I'm pretty sure they don't want
| to do that either because it would mean just as much code.
| ncmncm wrote:
| Yes. A different number, but you still have exactly all of
| the same problems as before.
| prpl wrote:
| the hard thing about TAI is that it's not properly
| supported in DBMS, RFC 3339/ISO 8601, etc... This makes it
| hard to use. It's actually easier to use MJD represented as
| a double.
| uoaei wrote:
| "Make two parallel time systems and allow conversion between
| one and the other programmatically" reduces spiritedly and
| unambiguously to "use one time system and care for it
| programmatically".
|
| By precedent, UTC seems the logical choice for the one time
| system.
| zozbot234 wrote:
| But the whole point of the OP is that UTC has leap seconds,
| which are hard to manage programmatically - and may even be
| impossible, wrt. future dates and times. That's literally
| the one relevant difference between UTC and TAI.
| ncmncm wrote:
| There is no need for UTC to continue inserting leap
| seconds. When they commit to stopping, everybody can
| relax: irritation removed.
|
| Telling people to use TAI is telling them to have a
| different time from everybody else. The whole point of
| civil time is specifically that other people use it.
| Using TAI does not free anybody, because anytime you need
| to interact with outside, you are back in the nightmare.
| zJlG wrote:
| I'm honestly amazed to see so many people agree with this.
|
| Timestamps are exactly what we define them to be. There is no
| correct and incorrect.
|
| One option is to have a system with arbitrary unpredictable
| leaps to keep it synchronized to within 1 second of the mean
| solar time over Greenwich, England. Every computer system that
| has to deal with time accurately needs a lookup table for leap
| seconds that is occasionally amended, with only a couple months
| warning in advance.
|
| Another option is to just let the clock run at a constant rate.
| In this case only astronomers have to keep track of the
| difference between solar time and clock time (which they
| already do anyway).
|
| The fact that the difference will increase to an hour after
| several hundred years is utterly irrelevant. If people in the
| future care, they can simply adjust the timezone definitions to
| compensate, since timezones are already adjusted all the time.
| modeless wrote:
| These "problems" are trivial. The day changes at midnight which
| is 12:00 AM by the clock. There is no ambiguity. Midnight is
| not literally the middle of the night. The minute on the clock
| will be correct by definition, nothing will change. Sundials
| are already wrong. You'll need to try a lot harder to convince
| me that this is a bad idea.
|
| All these arguments based on sun position make no sense in a
| world where people already live in places where the sun
| literally never sets or never rises for months, and people
| already live in time zones offset many, many hours from
| "correct" time. The sky doesn't fall!
| [deleted]
| [deleted]
| 3pt14159 wrote:
| If you stop thinking about time being wrong from what is
| officially correct, and instead see this whole exercise as a
| error minimization framework I think it is far easier to make
| the case for ending leap seconds as it is for keeping them.
|
| This isn't _just_ about lines of missing code. This is about
| forcing subterranean or submerged computers to surface. This is
| about out of sync clocks across information propagation
| networks across planets. This is about real lives that are
| ruined because time stamps didn 't quite line up, causing
| delays, deaths, and needless headaches.
|
| It doesn't need to be this way. We could just accept a minute
| of the clock being off from "true" midnight, which doesn't even
| make sense to me given that few people are right at the
| astronomic point where midnight is "true" midnight for their
| timezone. Heck, China is _one big giant timezone_ so who is
| this actually for, really? The people that care about sundials?
| Most people don 't even grow their own food.
|
| We're no longer a sun-driven economy. Well coordinated
| timekeeping across devices that may not always be able to
| transfer data is far, far more important. If it's sufficiently
| wrong by the year 3422 then we'll deal with the fifteen minutes
| of annoyance then. This is a crazy premature optimization.
| toast0 wrote:
| > Well coordinated timekeeping across devices that may not
| always be able to transfer data is far, far more important.
|
| How do you have a well coordinated clock without being able
| to get four bits [1] per year of leap second data? It's hard
| to keep within one second of a time standard over 6 months or
| a year without communication.
|
| [1] bit 0: was there a leap second in the most recent period,
| bit 1: was it positive or negative; bit 2: will there be a
| leap second at the end of the current period, bit 3: will it
| be positive or negative. Bike shed my fictious encoding if
| you like, but it's good enough. Use a whole 8-bits, go wild.
| aftbit wrote:
| Cesium reference clocks can operate with accuracy around
| 10^-14 (aka 0.01 parts per trillion). In a year, a cesium
| clock would slip by a few tenths of a microsecond. That
| said, the whole "submerged computer must surface" thing is
| a bit of a red herring argument IMO. What use case would
| you have for needing to keep time in sync within seconds
| with the outside world, but being unable to communicate
| with that world? If you're trying to plan simultaneous
| delayed action across the world, it would suffice to merely
| be in sync with each other, leap seconds ignored.
| fanf2 wrote:
| My encoding uses about 2.5 bits per year https://dotat.at/c
| gi/git/leapsecs.git/blob/HEAD:/doc/spec.md
| btilly wrote:
| We live in a world where civil time moves by an hour 2x a year
| for no good reason.
|
| You FAR overstate the impact on civil society of failing to
| change it by a second every so often.
|
| Ironically even astronomers, who leap seconds were originally
| for, don't benefit because they need to know the Earth's
| rotation accurately to subsecond levels.
| walnutclosefarm wrote:
| I don't see how you run into legal problems. The break from one
| day to the next still occurs at a well defined time, 23:59:59 +
| 1 second, or 00:00:00. Midnight isn't the middle of the night
| (or noon exactly at solar zenith), except on 15deg meridians
| anyway. What will happen is that over time, those "golden"
| meridians will shift slightly. The only people who will notice
| are those that are using time for celestial navigation.
| Terrestial navigation, which is almost entirely done with GPS
| these days, won't be affected at all (GPS already doesn't use
| leap seconds). And, yes, sundials will gradually get out of
| sync, and have eventually to be rotated on their axis to be
| right.
| lesam wrote:
| Sundials are already 'wrong' according to solar time by 30
| minutes or more, as an artifact of dividing the world into
| hour-wide time zones.
|
| Astronomy already ignores leap seconds in the same way that
| modern finance ignores half-crowns and shillings.
| welterde wrote:
| Astronomy very much relies on the leap seconds. If they ever
| get abolished it will create lots of headache for all
| observatories (and hobby astronomers as well), since the
| telescopes will point more and more incorrectly as UTC drifts
| away from UT1 (the leap seconds ensure UTC is always within
| 0.9s of UT1).
|
| To explain a bit further: UT1 tracks the Earth's rotation
| relative to distant quasars and is thus directly the correct
| clock/reference to use for pointing telescopes. However it
| doesn't advance at a nice and stable constant frequency, but
| something that slowly changes over time (and can shift by
| strong earthquakes) and thus we approximate it with UTC,
| which runs at a nice constant frequency, but needs occasional
| correction to match up with Earth's rotation.
| philwelch wrote:
| I think we can allow astronomers to keep their leap seconds
| without requiring them to be imposed on the entirety of
| civil society.
| welterde wrote:
| Why should all purpose be removed from UTC if the
| alternative without leapseconds (TAI) already exists?
| Just use that if you don't want leap seconds.
| ncmncm wrote:
| Because UTC _already_ has no other purpose than to be
| what everybody is already using. The leap seconds in UTC
| benefit literally nobody. But being a standard _is_ a
| purpose.
|
| Changing to TAI means you are different from everybody
| else, and _still_ have to fool with leap seconds to know
| what everybody else is using. Worst of all worlds.
|
| (Except Google smearing, which is even worse than that.)
| welterde wrote:
| That's literally not true, since we astronomers do use
| UTC as it is intended (since within 0.9s of the correct
| time is good enough, but being many seconds off isn't
| anymore for many applications). The argument that the
| legacy systems should maybe be updated is already being
| discussed elsewhere, so no need to rehash that.
| lovecg wrote:
| Well, having worked on legacy systems it's much easier to
| keep the existing protocol mostly unchanged than migrate
| the world to a different protocol. Even if the change is
| as "simple" as subtracting a constant integer everywhere.
| Just thinking about all the stored timestamps in all
| databases gives me a headache...
| Animats wrote:
| > It's frustrating that programmers want to redefine civil time
| just because it is "hard".
|
| Yes. Problems with delay time going negative usually come from
| not using CLOCK_MONOTONIC for delay time. CLOCK_MONOTONIC is
| usually just the time since system startup. It comes from QNX
| (which, being hard real time, had to deal with this first),
| made it into the POSIX spec around 1996, and is now available
| on all major OSs. But there's still software that uses time of
| day where CLOCK_MONOTINIC is needed.
|
| Then there's the smoothing approach. This document described
| Facebook's smoothing approach, which has a different smoothing
| period than Google uses.
|
| * Facebook/Meta: "We smear the leap second throughout 17 hours,
| starting at 00:00:00 UTC based on the time zone data (tzdata)
| package content." This is puzzling. What does the time zone
| package have to do with UTC?
|
| * Google: 24-hour linear smear from noon to noon UTC.[1]
|
| * AWS: Follows Google.
|
| * US power grid: Starts at midnight UTC and takes a few hours
| while all the rotating machinery takes 60 extra turns to catch
| up.
|
| Not sure what telecom is doing.
|
| [1] https://developers.google.com/time/smear
| jsmith45 wrote:
| > What does the time zone package have to do with UTC?
|
| The IANA TZ database includes information about leap seconds,
| and even supports the concept of "right" time zones in which
| the leap seconds are counted in the Unix timestamps. (Which
| violates the unix spec, and may cause problems with code that
| assumes it can do path like `1 day= 24*60*60`, but on the
| other hand, things like DST already make that unsafe).
|
| It is mostly likely simply the case that they are using the
| leap second data from the time-zone database as a convenient
| source of this data.
| Animats wrote:
| Ah. So that's where the leap second schedule is stored.
| ncmncm wrote:
| There is no schedule. Just a history of ad hoc
| announcements.
| cpeterso wrote:
| > Facebook/Meta: "We smear the leap second throughout 17
| hours
|
| Why 17 hours instead of 12 or 24? Something to do with 17
| being a prime number or some convenient divisor?
| layer8 wrote:
| A large part of the problem is that in software there is a
| traditional conflation of (a) time marks to measure elapsed time
| and (b) events where we want to know what their wall-clock
| date/time is. Those should in principle be kept separate. One can
| use a monotonic elapsed-time clock for the former and a
| calendar/wall-clock based clock for the latter. Conversion
| between the two shouldn't be done gratuitously, and have to be
| done with the awareness that the mapping to future wall-clock
| dates (and sometimes also to past ones) is subject to change.
| APIs and data types reifying that distinction would be helpful.
| ncmncm wrote:
| I.e., add huge complexity to everything for no benefit to
| anyone.
| layer8 wrote:
| As long as you have timezones that change over time, and e.g.
| DST changes, you have the complexity anyway. It is all simply
| an expression of the fact that (a) earth's rotation and
| movement around the sun isn't a steady clockwork with
| subsecond precision, and (b) timezones and calendars are a
| subject of political decision-making.
|
| It's therefore just not possible to easily equate coordinates
| of civil time with physical time, and the related facilities
| in software development shouldn't project an illusion to the
| contrary.
| ncmncm wrote:
| Geographic time zones are a completely separate matter.
| Dragging them in just muddies the water.
|
| The topic here is worldwide standard time, literally the
| same for everybody, and whether a million programs obliged
| to make tiny adjustments to it on a random, unpredictable
| schedule was a good idea.
|
| Anything fiddly and unpredictable a million programs have
| to get right will instead be got wrong.
| wyuenho wrote:
| This post brings back horrors when I was trying to figure out
| from the logs why there was a sudden doubling of requests and
| orders on 2016-12-31:23:59:59. This is the time I learned that
| Linux does not distinguish the leap second from the second before
| it. This led me down to a rabbit hole of reading up on what the
| representation of a leap second was and found that there was none
| for Linux timestamp. Fortunately, this was in December 2019. I
| can only imagine the pain SREs had to suffer from on 2017's New
| Year's day on top of Cloudflare going down.
| jheitmann wrote:
| Why does ntpd lose the smear on a restart? I would have thought
| that the current smear could be calculated purely based off
| current non-smear time, plus the config to say when to smear,
| which is presumably available upon restart.
|
| Also, why were non-linear smears thought to be desirable?
| Googling just turns up hand-wavy phrases like "easier on
| clients".
| hocuspocus wrote:
| I came to the comments for the same question about non-linear
| smearing.
|
| I found more details and motivation in this article:
| https://developers.redhat.com/blog/2015/06/01/five-different...
| randyrand wrote:
| Ya this sounds like bad design.
|
| > current non-smear time
|
| This is the server that keeps that time! ;)
|
| But IMO, the time keeping device should be a separate hardware
| module with battery backup that is never is restarted.
|
| The computer should not be keeping time to begin with.
| almog wrote:
| That was my thought too, pointing out why NTP smearing might be
| fragile is a crucial point in any argument against leap
| seconds, and the reasoning in this post are lacking (regardless
| of the conclusion's correctness).
|
| My only guess is that because smearing takes place at Stratum
| 2, if the network partitions part of the NTP servers downstream
| (Stratum 3+), they'll have an offset as large as T/(17 x 3600)
| (T being the partition duration in seconds). Yet I guess it
| must be something else for I cannot see why that won't be
| tolerable.
|
| More generally AFAIK the NTP RFC does not include smearing
| period, which is why the best practices are to only use
| smearing in a well controlled environment rather than on public
| facing NTP networks, but why is this not something that can be
| fixed? I'm not sure.
| mritun wrote:
| A million problems started when system clocks were changed to
| follow UTC (as opposed to local time) and then UTC was conflated
| with Unix time - a fixed monotonic reference, which UTC is not!
|
| Though the ship has sailed, I think it could have been much
| better if computers were set to follow TAI Time (atomic clock
| time - unaffected by leap seconds) time than the UTC. UTC is as
| variable as localtime and should have been treated as such.
|
| If fb wants to - they can (and should) use TAI time for system
| reference.
|
| TAI : https://www.nist.gov/pml/time-and-frequency-division/nist-
| ti... edit: link
| ncmncm wrote:
| The ship has not, in fact, sailed: UTC could abandon leap
| seconds _any time_. They just need to announce there won 't be
| any more, for the foreseeable future. Along about 2100 they
| might announce plans for a correction in 2125 or so.
| kosherhurricane wrote:
| It seems the problem of adopting TAI for computers is because
| the NTP protocol does not provide the offset. We should add
| TAI-UTC offset to the NTP protocol.
| vesinisa wrote:
| This sounds like a sensible solution. If Facebook wants to
| start using non-UTC time coordination, like TAI, they by all
| means should try it. They only need to publish their own NTP
| servers I guess, but that shouldn't be a big problem for an
| organization of their size.
|
| As far as I can tell, TAI will always be offset from UTC by an
| integer amount of full seconds, and I guess time coordination
| between large independent systems is mostly useful just when
| comparing log timestamps (I would guess almost all sensible
| software uses already account for much larger clock drifts than
| the current leap second count of 37, right?)
|
| After adopting TAI, Facebook engineers just need to remember
| that their log timestamps are offset by N seconds from all the
| others.
| ncmncm wrote:
| Not all the others. Just those who have not made the
| similarly wise choice.
| NovemberWhiskey wrote:
| Unix time is definitely not a fixed monotonic reference; in
| fact it's defined explicitly to exclude leap seconds in the
| count since the epoch...
| kosherhurricane wrote:
| I totally support this. In fact, I would say all computer
| systems should just use TAI, and display UTC to the user.
|
| Someone should fork the NTP protocol to use TAI instead, and go
| from there (or at least provide tai offset).
| joerichey wrote:
| This is actually what the Precision Time Protocol (PTP) does.
| It's the successor to NTP, so it improves on some of NTP's
| mistakes. The protocol uses TAI, but also sends the TAI-UTC
| offset so the computer can display times in UTC.
|
| https://en.wikipedia.org/wiki/Precision_Time_Protocol
| luhn wrote:
| Why does the time protocol need to send the UTC offset,
| rather than have the offset be part of system data files,
| like with timezones? Wouldn't you need the data anyways to
| translate historical timestamps to UTC?
| mongol wrote:
| Seems like a simple and accurate way to handle it.
| SkeuomorphicBee wrote:
| Those are two different problems that require two
| different solutions:
|
| 1. Displaying current time: for that ideally you need the
| offset directly from the time server because the system
| timezone data can be out of date in regards to current
| time.
|
| 2. Displaying historical timestamps: for that you use the
| system timezone file.
| kosherhurricane wrote:
| I think this is the argument NTP makes for not including
| the offset. TAI can be just another "timezone", so that
| TZDATA should be to used it to derive it.
|
| But that's backwards. A Stratum 1 NTP usually gets its
| data from GPS, which HAS the offset (GPS runs TAI). But
| it only outputs UTC, but not the offset, making other
| programs compute it from TZDATA. Why is NTP making user
| programs harder to get the data that IT ALREADY HAS?
| Because philosophically, NTP is married to UTC (even
| though NTP is mostly for computers!)
|
| And providing this offset would basically get rid of a
| large body of people (like the TFA) who wants to CHANGE
| the definition of UTC, which is a more drastic proposal.
| fanf2 wrote:
| PTP and NTP have completely different scopes: PTP requires
| end-to-end layer 2 support and hateful choice of hardware,
| so it can only work within a single network; NTP on the
| other hand was always designed to work across the internet
| between different organizations, where the network doesn't
| help with timekeeping and the organizations don't work
| closely with each other.
| bloak wrote:
| This topic keeps coming up and I'm not sure I want to read all
| the comments just in case someone has written something that
| wasn't written last time it was discussed.
|
| Personally, I would like to keep leap seconds. The only change I
| would make is to demand a longer notice period: 18 months instead
| of 6 months would be good. Presumably that would mean we'd have
| to tolerate a slightly bigger difference between UTC and UT1 but
| that seems all right.
|
| It would be stupid and irresponsible to abolish leap seconds
| without deciding on and implementing an alternative way of
| keeping time, and therefore the calender, in phase with the cycle
| of daylight. There are alternatives (leap minutes, redefining the
| second, ...) but to me they all seem a lot worse than leap
| seconds.
|
| Of course, whatever we do in the future, software will still have
| to handle leap seconds for processing timestamps in the past so
| any change to the system would mean that most software gets more
| complex.
| Asmod4n wrote:
| Will satnav become unusable when leap seconds get abolished?
| ncmncm wrote:
| No. GPS (which I assume you mean) is already based on TAI.
| makeworld wrote:
| This article includes a Go code example: start :=
| time.Now() // do something spent :=
| time.Now().Sub(start)
|
| It's worth noting that the Go time library is specifically
| designed so that computer clocks running backwards won't cause
| `spent` to be a negative duration. A monotonic clock that only
| ticks forward is used for time comparison and subtractions.
|
| Source: https://pkg.go.dev/time#hdr-Monotonic_Clocks
| klabb3 wrote:
| Hehe, story time: I was using exactly this logic to detect
| hibernation/sleep, especially for laptops. I was surprised when
| it never triggered, and printed the time, which indeed showed
| that a long time had passed. So why didn't it trigger? Because
| IFF both time stamps have monotonic component (internal, not
| visible on print) then the monotonic stamp is used. Confused me
| a lot.
|
| One man's bug is another man's feature.
| ForHackernews wrote:
| Counterproposal: Facebook turns off their servers during the next
| leap second.
| mro_name wrote:
| IMO it's time to leave fb in the past.
| gmiller123456 wrote:
| This periodic adjustment mainly benefits scientists and
| astronomers as it allows them to observe celestial bodies using
| UTC for most purposes
|
| This is incorrect, dealing with leap seconds is a major problem
| in astronomy, requiring a data file or even recompile any time
| there is a new one announced. Since they are only ever announced
| 6 months in advance, it creates a lot of logistical problems.
|
| Astronomy algorithms usually work in Barycentric Dynamic Time, or
| Terrestrial Time, or UT1. In reality the whole invention of UTC
| is so that people don't have to deal with those systems on a
| daily basis.
|
| The process most astronomy programs go through is to get the UTC
| from the user, convert the Gregorian date to a Julian day number
| to get rid of the Gregorian Calendar altogether. Then look up the
| number of leap seconds, add those to the JD to get International
| Atomic Time, then add 32.184 seconds to get Terrestrial Time. If
| Barycentric Dynamic Time is needed, you must first compute the
| velocity of the Earth relative to the solar system barycenter
| (which itself requires TDB), then compute the relativistic
| effects of that motion on Terrestrial Time. If you need UT1,
| these can only be obtained by observation from the International
| Earth Rotation Service, and required daily updates, and
| interpolation of values in between observations.
|
| So, as you can see, leap seconds do nothing to make an
| astronomer's life easier. In fact, we jump through a lot of hoops
| to make the average person's life easier. It sounds like Meta
| wants to change the definition of time for everyone just to make
| their programming a little easier. I find the very premise just
| out right ridiculous.
|
| It's true that your average person will not be affected by the
| Sun setting a few seconds earlier. But eventually it will build
| up enough error that it eventually has to be addressed, and Meta
| is just trying to make their problem someone else's problem.
| salty_biscuits wrote:
| I always heard that the main reason for the leap second was
| that the british didn't want the prime meridian moving away
| from Greenwich (i.e. it is a weird political thing).
| oconnor663 wrote:
| The article makes the same point a couple of sentences later:
|
| > these days UTC is equally bad for both digital applications
| and scientists, who often choose TAI or UT1 instead.
| gmiller123456 wrote:
| UTC was never to make astronomy applications easier. The only
| thing that has changed is that cheap computers make it easier
| for astronomers to use UTC as a starting point.
| ncmncm wrote:
| Then it was for nobody. Astronomers find UTC leap seconds
| as much a nuisance as everybody else.
| willis936 wrote:
| It's not just a headsche for Meta's programmers. Anyone
| involved with bookkeeping and synchronizing has an unnecessary
| bugbear to deal with. Every six months is simply too often. If
| it was switched to an adjustment made every 2-10 decades with
| at least a decade to update the file then the problem would be
| greatly lessened.
| msbarnett wrote:
| > Every six months is simply too often. If it was switched to
| an adjustment made every 2-10 decades with at least a decade
| to update the file then the problem would be greatly
| lessened.
|
| You seem confused. It doesn't _happen_ every 6 months, it
| gets announced 6 months in advance - since we know there won
| 't be one this year, it will have only happened twice total
| in the 10 years prior to December this year.
|
| That's _hardly_ an enormous and constant disruption - turning
| it in to a multi-minute disruption "every 10 decades" would
| likely be _more_ concentratedly disruptive, leading to more
| calls to put it off to avoid the immediate pain, leading to
| ever-more accumulated error.
|
| Spreading the pain out into a leap second every few years
| feels like a much better and more sustainable solution. This
| keeps processes in-use and up-to-date rather than long-
| forgotten-and-everyone-who-knew-them-is-dead.
| ncmncm wrote:
| I guess you also brush 3 teeth in each of 11 interruptions
| thoughout your day, and again all night.
| aftbit wrote:
| I guess you brush your teeth for one hour once a month.
| BurningFrog wrote:
| It's moved 7 seconds the last 25 years, so over 10 decades
| it should be about 28 seconds, not a multi-minute
| disruption.
|
| Source: https://endruntechnologies.com/support/leap-seconds
| [deleted]
| gmiller123456 wrote:
| It isn't every six months, the Earth doesn't rotate that
| regularly. They are introduced "at most" every 6 months, but
| usually far less. There have been 27 leap seconds since 1972,
| so less than one a year.
| msbarnett wrote:
| 27, not 37
| gmiller123456 wrote:
| Thanks, I corrected it.
| hannasanarion wrote:
| Palestine switched off Daylight Saving Time this year with
| only 4 days notice.
|
| Anyone involved with bookkeeping and synchronizing should
| already know to never attempt to handle time conversions
| using your own program logic updated by hand, because the
| definition of time is constantly changing and there are
| already projects like tzdata dedicated to centralizing the
| handling of it.
|
| There have already been 5 time zone updates this year, 4
| changes to the date that Palestine switches daylight savings
| (one of them with only four days notice!) and Fiji decided to
| quit using daylight saving time, plus the Leap Second
| announced on July 9.
| alerighi wrote:
| That is a different problem. You usually work with
| timestamps and then convert the time to local time only
| when displaying it or doing calculations that depend on the
| particular timezone. So it's less of a problem, since at
| lower levels you don't have the concept of timezone (you
| may never have it, for example on embedded devices).
|
| But if UTC shifts, it's another story. You assume the UTC
| (or UNIX) time to be a monotonic counter, and usually it's
| used this way, for example you compare two timestamps to
| know what definitively happened before another thing.
| Surely you don't take into account leap seconds... this is
| the problem.
|
| Leap seconds wouldn't be that much of an issue if the time
| is only increased, you have one more second, it's the
| higher level implementation that has the concept of time to
| (maybe) deal with it. But they become an issue if they can
| take behind the UTC clock since it can generate all sort of
| strange bugs.
|
| It's even a worse solution to make the duration of a second
| in a day longer or shorted, because you preserve the
| counter value, but you no longer can rely on the fact of 1
| seconds being 1000ms long!
|
| By the way the concept of leap second is nonsense to me.
| What is the purpose? If the purpose is to keep in sync the
| time with the rotation of the earth, nobody will ever
| notice an error of a couple of seconds, or even minutes. It
| makes more sense to take the current definition of a
| second, and then wait till the error is noticeable to an
| human being (let's say an error of 15 minutes, that would
| take centuries and we will probably far gone from the
| planet) and adjust it by shifting all the timezone for that
| amount of time.
| a9h74j wrote:
| > and adjust it by shifting all the timezone for that
| amount of time
|
| Does this follow as a question?: Shift the timezones
| geographically, or in terms of how they all define [true
| monotonic] to local-time translation?
| yyyk wrote:
| Reminds me of this story:
|
| https://darwinawards.com/darwin/darwin1999-38.html
| aeyes wrote:
| Why is this too often? We already need to update tzdata
| continuously.
|
| The problem is that it is not often enough to force you to
| have a good process in place.
| vbezhenar wrote:
| So another option is to adjust to 1/100 second every few
| months, so good processes will have to appear, one way or
| another.
| tablespoon wrote:
| > It sounds like Meta wants to change the definition of time
| for everyone just to make their programming a little easier. I
| find the very premise just out right ridiculous.
|
| It's also incredibly common attitude amongst software engineers
| and software engineering organizations. "Simplify" often means
| push complexity off of us and onto others.
|
| > ...Meta is just trying to make their problem someone else's
| problem.
|
| Exactly right.
| yunohn wrote:
| Even NIST (1) claims that leap seconds are added to sync UTC
| with IAT.
|
| Your point is that astronomical systems don't use IAT directly
| but instead start with UTC and convert across various other
| systems? Could be, but then the purpose of UTC syncing was lost
| somewhere. Any idea why?
|
| (1) https://www.nist.gov/pml/time-and-frequency-division/leap-
| se...
| zokier wrote:
| Navy celestial navigation. Naval almanacs by necessity were
| based on rotation of earth, so that was the timescale that
| naval organizations broadcast across the earth to support
| their ships. Eventually that radio broadcast time morphed
| into UTC, and then was repurposed as general-purpose civil
| time.
| jefftk wrote:
| _> So, as you can see, leap seconds do nothing to make an
| astronomer 's life easier. In fact, we jump through a lot of
| hoops to make the average person's life easier. It sounds like
| Meta wants to change the definition of time for everyone just
| to make their programming a little easier. I find the very
| premise just out right ridiculous._
|
| Meta (and everyone else behind this proposal) are arguing that
| leap seconds are more trouble than they're worth. Just as you
| are in the specific case of astronomy.
| bnjms wrote:
| > But eventually it will build up enough error that it
| eventually has to be addressed
|
| I also misread their argument until this point. But there is
| no reading that makes sense except that Meta's programming
| problems protect everyone else from dealing with the drifting
| time.
|
| I think this is right. There will still be calculations for
| sunrise and sunset which will have to make the calculations.
| teknopaul wrote:
| Seconds don't matter for sunset and sunrise to humans. Move
| a bit and your off no matter what timezone you are in. If
| you need really really precise sunset and sunrise leap
| seconds don't help. You are more likely to hit a bug than
| be helped by them. I'm all for ending leap seconds and
| ending daylight savings while we at it. In Spain, in
| summer, some people start work at 08:00 or 07:00, no need
| to change clocks to change habits.
| gmiller123456 wrote:
| All I did was make the argument that they didn't make an
| astronomer's life easier, at no point did I say it was more
| trouble that it's worth.
| alecbz wrote:
| You also said:
|
| > It sounds like Meta wants to change the definition of
| time for everyone just to make their programming a little
| easier. I find the very premise just out right ridiculous.
| ... Meta is just trying to make their problem someone
| else's problem.
|
| Meta's argument is: we should get rid of leap seconds
| because even though they're helpful for astronomers,
| they're bad for everyone else.
|
| Your counterpoint was: Actually leap seconds are _also_ bad
| for astronomers.
|
| Which implies then that Meta is even more right to suggest
| that we get rid of leap seconds, because it seems like they
| help nobody.
| panda-giddiness wrote:
| Their point is that Meta's argument is a straw man.
| alecbz wrote:
| It's not really a straw man because Meta's not really
| attacking that position, they're ceding that point.
|
| Like a straw man would be Meta saying "astronomers think
| that leap seconds are helpful but in fact they're not
| useful for anything!"
|
| Here, if anything, Meta is attempting to steel man leap
| seconds a bit by saying "look, sure, leap seconds are at
| least useful for some things, like astronomy, but they're
| still not worth it overall". And GP is claiming that it's
| not a very good steel man because even astronomers don't
| like leap seconds.
| panda-giddiness wrote:
| But Meta's not _actually_ ceding the point. They 're
| essentially arguing that (1) leap seconds are an esoteric
| concept that only astronomers care about, and that (2) we
| shouldn't care about their esoteric concerns, so (3) we
| should therefore dispose of leap seconds.
|
| The GP's point is that astronomers find leap seconds
| annoying too, so Meta's argument is based on a faulty
| premise.
| alecbz wrote:
| Ok sure, I don't think I quite got that from what GP
| wrote, but I can see that as a valid argument: "There
| _are_ actually valid uses for leap seconds, but just not
| within astronomy. Meta 's claiming that leap seconds were
| made for astronomy so that we assume that's why they
| exist and ignore the other _real_ reasons leap seconds
| exist and the benefits they provide. "
| panda-giddiness wrote:
| Yup, that's precisely how I interpreted GP's comment.
| ncmncm wrote:
| They do not provide any.
|
| Unless it is "programmers' employment assurance".
| ncmncm wrote:
| No. Astronomers deal with the problem leap seconds
| pretend to do with their own, more precise methods.
|
| If the actual leap seconds do not benefit astronomers,
| _and_ do not benefit anyone else, they are purely a tax
| on us all.
|
| Abandon leap seconds in UTC, and _literally everybody_ is
| better off. Even astronomers, who would go from managing
| 3 time systems to just two.
| VMG wrote:
| It isn't. Metas argument is valid even ignoring
| astronomers.
| gmiller123456 wrote:
| I can see how you'd read it that way, but my point was
| that they were not invented for astronomers, with the
| implication being the author didn't research the topic
| thoroughly enough to be making recommendations.
| jefftk wrote:
| Astronomers have been one of the groups most vocal in
| favor of retaining leap seconds:
| https://www.nature.com/articles/423671a
| ghshephard wrote:
| You have one of my favorite comments on this entire
| thread - so I'm interested in your thoughts on who leap
| seconds are useful for, if not Astronomers (and clearly
| not Meta).
| gmiller123456 wrote:
| They are useful for ordinary people. Without them, at
| some point in the future people would go to work at 8am
| at sunset and go to bed at sunrise. Leap seconds are a
| way for everyone to agree to shift their schedules by 1
| second to stay in sync with solar time. It's subtle
| enough that most people don't even know they exist, nor
| will it have an effect on most systems. Larger jumps
| would be much more difficult to ignore, and smaller jumps
| would be more frequent.
| jefftk wrote:
| How long from now are you talking about? Eyeballing it, I
| think it would take us about a thousand years to get off
| by an hour?
| staticassertion wrote:
| We change our clocks twice a year by an _hour_ I think we
| could handle an hour every millenia.
| gmiller123456 wrote:
| The physical effort of setting a clock is not the issue.
| Switching to "leap hours" would involve a good part of
| the world living with about 9am sunrise (or a 3:30pm
| sunset) for hundreds of years. It'd be a really hard sell
| to say that's actually better. DST is adjusting to the
| amount of daylight available, so there's not much of a
| negative impact. Systems that need to be more accurate
| just set their time zones to UTC. And one second every
| year or so is far within the accuracy of a typical
| computer clock, so anything that needs something better
| is already going to have a complex time synchronization
| system.
| alistairSH wrote:
| And, by some accounts, every time we do, auto deaths and
| other _bad things_ increase for some period after the
| change. Not to mention the weeks of bitching on either
| side of the change about how bad /great the time change
| actually is.
| staticassertion wrote:
| One second every thousand years.
| jefftk wrote:
| Do you mean one hour?
| alecbz wrote:
| In that case I don't think I understand what you mean by:
|
| > Meta is just trying to make their problem someone
| else's problem.
|
| It sounds like you agree that leap seconds themselves are
| a problem for people besides Meta?
| [deleted]
| exabrial wrote:
| > Meta is just trying to make their problem someone else's
| problem.
|
| Business as usual
| a9h74j wrote:
| MAT -- Meta Adjusted Time. AFAIK 'mat' is also a [Sanskrit??]
| word for truth.
| emmelaich wrote:
| That's in the article!
|
| > _While the leap second might have been an acceptable solution
| in 1972, when it made both the scientific community and the
| telecom industry happy, these days UTC is equally bad for both
| digital applications and scientists, who often choose TAI or
| UT1 instead._
| lucb1e wrote:
| for anyone else wondering about TDB:
|
| > Barycentric Dynamical Time (TDB, from the French Temps
| Dynamique Barycentrique)
| brandmeyer wrote:
| > If you need UT1, these can only be obtained by observation
| from the International Earth Rotation Service, and required
| daily updates, and interpolation of values in between
| observations.
|
| The GPS CNAV messages (on L2C and L5) have support for the
| Earth orientation parameters, but GPS isn't broadcast those
| messages yet. Maybe we'll get them with the OCX deployment.
| BeiDou 3 is transmitting the Earth orientation parameters now.
| So this one tiny bit of your headache will get easier in the
| near future as receivers start to forward these data along.
| barnabee wrote:
| There is literally no aspect of society, science, or culture that
| I'm willing to buy into changing to make things easier for
| software developers and tech companies (or in fact any companies,
| but only tech companies seem to be arrogant enough to suggest
| it). What an entirely backwards way of looking at the world.
|
| If we can't deal with IT that improperly models the universe, the
| right answer is not to change the world to be more like the
| shitty naive model the software implements, it is to be less
| dependent on the technology agreeing 100% with reality.
| Beltalowda wrote:
| But what benefit are leap seconds to "society, science, or
| culture"? I've never seen one.
|
| If the current drift would continue then we're talking about a
| drift of 9 minutes every millennium; less than an hour for all
| of recorded history (and it mostly likely won't continue as-is;
| sooner or later we'll get negative leap seconds).
| barnabee wrote:
| The current situation doesn't need to benefit society to
| oppose changing it for Facebook. Society, science, and
| culture are not the result of some utilitarian optimisation
| function, and that is precisely the reason to oppose changing
| them simply to make some company's engineering slightly
| easier (or even a lot easier).
| jefftk wrote:
| It sounds like you would have been opposed to the introduction
| of timezones? They made everyone switch away from local solar
| time, primarily for the benefit of railway timetables.
| nrvn wrote:
| This is me.
|
| I want everyone to use UTC and align local lunch times to
| solar noons.
| barnabee wrote:
| I'm not particularly attached to time zones, so perhaps I
| would have opposed introducing them.
|
| Sticking with local solar time in the age of jet planes would
| have been _at least_ as much fun as daylight saving time.
| dclaw wrote:
| Delete facebook.
| [deleted]
| [deleted]
| gumby wrote:
| Strongly disagree. As the article itself points out, people who
| need it can already use TAI or UT1.
| amenghra wrote:
| IMHO, leap seconds belong at the timezone layer. I.e. ignore it
| internally and for things like "seconds since epoch". Adjust at
| display time.
|
| Timezones are already backed by a database which needs regular
| updates, including leap seconds would make sense since those are
| also updated in an unpredictable manner.
| ncmncm wrote:
| That is what we are all obliged to do already. It is a source
| of headaches and bugs. That is what is being asked to drop.
| amenghra wrote:
| Not really. Time smearing isn't moving the leap second into
| just a rendering thing.
| ncmncm wrote:
| Time smearing is its own bucket of nightmares.
| benlivengood wrote:
| The bigger problem is that UTC (and TAI) is defined in a gravity
| well so it's not going to be very useful in the long run. GPS has
| to correct its clocks to keep track of what we slow
| Cesium/Rubidium down to on the surface, and Voyager's clock is
| going even faster. We clearly want an Earth-centric time standard
| for wall clocks and that is UTC. The Earth is not a precision
| time-piece so we will always have to adjust our wall clocks to
| its rotation. Realistically, we should probably be deriving a
| time standard where every day has a slightly different length and
| we record the timestamps of the beginning of each day relative to
| a universal monotonic clock in a log (with rollups to years,
| centuries, etc.) that we keep around as long as anyone cares
| exactly how many Cesium vibrations have happened since $whence.
|
| If we want to actually solve the problem then let's switch to an
| interstellar time standard in a rest frame relative to the CMBR
| as far outside of gravity wells as possible and make that the
| universal monotonically increasing standard. Then computers can
| run on that time standard and UTC and friends can be derivatives.
| Enginerrrd wrote:
| I'm not sure it matters. To synchronize, you'll have to make
| corrections either way, and over sufficiently large scales,
| signal propagation delays are going to be quite large.
| benlivengood wrote:
| Here my physics knowledge gets a little sketchy, but if we
| have an accurate clock broadcasting on a known frequency
| somewhere far away we should be able to at least measure the
| drift between it and a local clock to arbitrary precision.
| With ~zero drift we can measure the distance and relative
| velocity very accurately with round-trip timing and Doppler
| measurements, and from that measure the clock offset as
| accurately as we can measure the distance. I think, but could
| be wrong, that we'd always be measuring the spacetime
| interval, not the euclidean distance in space, but that is
| probably what we actually want once we start caring about
| relativistic timekeeping.
| a9h74j wrote:
| > let's switch to an interstellar time standard in a rest frame
|
| Timex(TM) Watches, now featuring Puslar(TM) Time.
| Denvercoder9 wrote:
| > let's switch to an interstellar time standard in a rest frame
| relative to the CMBR as far outside of gravity wells as
| possible
|
| This won't work: since galaxies aren't static, and because the
| universe expands, the point with the highest gravitational
| potential ("as far outside of gravity wells as possible") will
| both move w.r.t. the CMBR and have a gravitional potential that
| changes over time.
| benlivengood wrote:
| Maybe I'm making a bad assumption that intergalactic space is
| so flat that pretty much any region of it will do as a
| reference. Since we can't reach those regions yet we'd still
| be approximating it with our slower clocks, but it seems like
| it's at least feasible.
| ncmncm wrote:
| Your proposal is to make the time Standard of billions of
| people not match what they experience, on behalf of a few space
| probes, none of which will use it.
| mgaunard wrote:
| Anyone doing precise timestamping uses TAI.
|
| Converting to UTC is easy when you need it.
|
| Meta's suggestion just shows how narrow-minded they are.
| ncmncm wrote:
| You have very evidently not thought it through, and are then
| accusing others of it.
| bakul wrote:
| Wouldn't it be less of a disruption if we standardize how
| smearing is done?
| ncmncm wrote:
| Smearing is overwhelmingly more disruptive than anything else
| that has been done.
| rossdavidh wrote:
| Situation: there's a problem, and our current way of coping is
| something we've done 27 times so far.
|
| Reaction: let's stop using the system we have some practice at
| doing, and instead open up the question again, but really just
| have big tech corporations dictate to the world that we need to
| do something else.
| ncmncm wrote:
| 27 times, _badly_. Every time, 27 times over, it has been a
| serious hassle, for exactly zero benefit to anyone.
|
| Choosing not to impose a hassle and source of bugs on millions
| of people every year or two is _obviously_ correct.
|
| Anyone who wants to use what astronomers use will still be free
| to do that, without bothering literally everybody else.
| jefftk wrote:
| We may soon have the first negative leap second. This isn't
| something we've ever done before.
| SoftTalker wrote:
| Might be before many people's memory here, but Swatch tried to
| create an "internet time" in the late 1990s. Nobody uses it
| because it doesn't solve any problems anybody has, it's just
| different.
| [deleted]
| pbnjay wrote:
| No mention that Go actually fixed the stdlib so that the code
| shown won't have this issue again.
|
| Some discussion of the issue and the fix implemented start around
| here:
| https://github.com/golang/go/issues/12914#issuecomment-26993...
| ncmncm wrote:
| Go cannot fix it in the library. It always leaks out.
| exabrial wrote:
| Which isn't why we created to Unix Epoch anyway? The number of
| seconds since an arbitrary event, with no regard of the movement
| of celestial bodies?
|
| And isn't Unix Epoch derived from some sort of Atomic clock
| standard? I can't remember, but it seems all of our systems time
| should be atomic time, then you can derive UTC or whatever you
| want from that.
| ajaimk wrote:
| Engineers whining about having to do work that was designed in
| the past by someone else and coming up with a "creative" hack
| which will be a headache for someone in the future.
| ncmncm wrote:
| You wholly miss the point. A million programmers have to all,
| unanimously get a fiddly, hard to test detail right. Both those
| that do and those that don't get periodically out of sync with
| the other half, on a random schedule applied for no earthly
| purpose.
|
| Dropping any new leap seconds is choosing not to break a
| million systems, irregularly, to no purpose. No code needs to
| change. Things just stop breaking.
___________________________________________________________________
(page generated 2022-07-25 23:00 UTC)