[HN Gopher] The Earth has been spinning faster lately
___________________________________________________________________
The Earth has been spinning faster lately
Author : jameshart
Score : 64 points
Date : 2021-01-08 13:48 UTC (9 hours ago)
(HTM) web link (phys.org)
(TXT) w3m dump (phys.org)
| epicureanideal wrote:
| Elon Musk is cackling in his lair.
|
| "Mwahahahaha! It works, it works!"
|
| His assistant types onto their tablet... Test of MegaRaptor
| Engine successful.
| quijoteuniv wrote:
| Must be because the earth is flat now
| ProAm wrote:
| A negative leap-second will be crazy interesting given how the
| first few leap seconds in computing caused a little havoc.
| toast0 wrote:
| A removed leap-second is gobs easier to handle. I can't say if
| it will or won't be handled properly, because I never tested
| it, but roughly you have three options:
|
| a) software ignores it, and your clock is a second behind as of
| the discontinuity, and adjusts eventually
|
| b) software handles it properly and jumps ahead
|
| c) software handles it by explicitly dithering the difference
| over a day
|
| d) c, but it also jumps ahead at the discontinuity
|
| e) your network has a mix of b, c, and d, resulting in wonky
| clocks throughout the day, but generally still +/- 1 second of
| real time. This could be problematic for forensics, or for
| distributed software that uses time as measured on nodes to
| determine order of operations, but using time as measured on
| nodes requires constant vigilence to ensure clocks are in sync
| enough.
|
| An added leap second is a lot trickier because at least Linux
| and FreeBSD simply repeat the last second of the minute at the
| discontinuity if you don't take special action to dither it.
| That brings two new problems:
|
| a) real time is no longer monotonic
|
| b) a logic error can result in repeating that second forever
| Ericson2314 wrote:
| I don't think positive or negative makes much difference.
| Whether we speed up or slow down we can still "make it
| monotonic".
| BitwiseFool wrote:
| Woudln't it be easier to just "let it ride" and the next time a
| leap second is due, just not add it?
| throwaway894345 wrote:
| It's interesting to think about the ramifications of
| decoupling our measurement of time from the earth's position
| in the solar system. For example, when we read that something
| happened around 11 AM, we know that it's probably daylight
| time, but if we allow for drift, then we can't make that
| assumption anymore for certain timescales. If the error is
| small, we can probably deal with it the same way most people
| understand that dollars in 1950 don't have the same value as
| dollars today.
| myself248 wrote:
| Unless you're within a few feet of the longitude of the
| center of the timezone, this is already the case.
|
| That ship sailed, back in the railroad era when we decided
| to standardize time away from mean solar time.
|
| If we assume that the Gregorian calendar remains in use for
| as long as it's already been in use, the total accumulated
| error would likely be on the order of minutes. We could use
| a monotonic time scale like TAI for literally centuries and
| nobody would notice except astronomers, and arguably it
| would simplify astronomical corrections too because the
| underlying scale would be monotonic, which it isn't
| presently.
| throwaway894345 wrote:
| Yeah, I'm musing abotu the possibility of using monotonic
| time. Right now, our time system conveys implicit
| information about the "solar time of day" (whether or not
| its daylight in the locale) as well as season (January is
| winter in the Northern Hemisphere). For monotonic time,
| you would have to use some sort of conversion function to
| recoup that information. As we both noted, certain
| monotonic time systems could be used which deviate very
| little from solar time such that the accumulated error
| would only make a difference (for the purpose of
| recouping that aforementioned implicit information) at
| very large time scales, which is a problem we already
| face with inflation (1950s dollars are not the same value
| as 2021 dollars and we all seem to manage alright with
| that).
| klodolph wrote:
| > That ship sailed, back in the railroad era when we
| decided to standardize time away from mean solar time.
|
| I'll make the case here that we still use mean solar
| time, we just quantize it and push it around for
| political reasons. In any case, using time zones just
| means that your clock is off by maybe a half hour or 45
| minutes in the lower US, and given the natural variation
| for sunrise and sunset, that doesn't seem like an
| outrageous amount of error for temperate latitudes.
|
| Granted, there are a few places in the world with larger
| differences, like Spain or western China, or Argentina
| for some reason.
|
| Changes in the period of the Earth's rotation have been
| estimated based on records of eclipses from as far back
| as the 8th century, which show that the Earth's
| rotational speed is slowing down. Trying to extrapolate
| from fifty years of atomic time is going to give you the
| "on the order of minutes" estimate which is likely wrong.
| If you are trying to work out the error over five
| centuries, you should probably be using the best
| available data, which is records of eclipses and
| ephemerides.
| wcoenen wrote:
| Note that we don't sync to the Earth's position in the
| solar system (sidereal year), but to the seasons (tropical
| year).
| Archelaos wrote:
| GPS time is like this. See: https://en.wikipedia.org/wiki/G
| lobal_Positioning_System#Time...
| anigbrowl wrote:
| Suppose for argument's sake that this year produces shorter
| days, and the trend continues.
| tantalor wrote:
| _A negative leap second would suppress second 23:59:59 of the
| last day of a chosen month so that second 23:59:58 of that date
| would be followed immediately by second 00:00:00 of the
| following date. Since the introduction of leap seconds, the
| mean solar day has outpaced atomic time only for very brief
| periods and has not triggered a negative leap second._
|
| https://en.wikipedia.org/wiki/Leap_second#Process
| layer8 wrote:
| Just a quick reminder that this is in UTC. The missing second
| will be at varying times of day depending on time zone.
| Avamander wrote:
| Sounds worth it to me honestly, sets a precedent that it's
| possible and it's harder to ignore the possibility in future
| software.
| temptemptemp111 wrote:
| Amazing what supposedly smart people will believe.
| anigbrowl wrote:
| I love the idea of switching to atomic time. Using a different
| paradigm to conceptualize it could lead all sorts of whimsical
| new approaches to representing it, and where whimsy wanders new
| insights and discoveries often ensue.
| layer8 wrote:
| On the one hand I agree. On the other hand the discrepancy to
| solar time is growing quadratically due to tidal friction of
| the earth with the moon, which is prone to create interesting
| issues some centuries down the line.
| swebs wrote:
| By then, hopefully civilization won't be bound to just the
| Earth.
| rohan1024 wrote:
| And adopted the decimal calendar[0] which hopefully has
| fixed all the issues with current calendar.
|
| [0] https://medium.com/@duspom/proposal-for-a-
| base-10-calendar-b...
| ljm wrote:
| > I believe this would be more than outweighed by the
| increased productivity of fewer weekends and longer
| periods of contiguous work between them.
|
| I don't think that's how productivity works
| dwheeler wrote:
| It's weird to talk about "switching" to atomic time. If you
| want seconds to always go 58,59,0, and you want time to always
| increment 1 second at a time, then UTC has _never_ been
| appropriate. People who need to measure time this way should
| already be using TAI or GPS Time (which do this). Many people
| _already_ do this, there 's no "switching" needed.
|
| However, most civilian applications want a time that is
| synchronized, to bounded degree, to the Earth's rotation. UTC
| has leap seconds, which are occasionally added or removed, to
| make that happen.
|
| There's been a push for removing leap seconds from UTC, because
| that'd be convenient for computers. But no one's figured out
| how to change the Earth's speed to match this new definition of
| UTC :-). So if we want time-of-day to be related to the
| position of the sun in the sky, adjustments like leap seconds
| are necessary.
| segfaultbuserr wrote:
| > _It 's weird to talk about "switching" to atomic time._
|
| The biggest reason to describe it as "switching from UTC to
| TAI" (at least for me) is due to Unix time. Unix time is an
| elegant concept at first glance, ideally it's a free-running,
| monotonic counter that abstracts us away from timezone
| problems, an unambiguous representation of time. You only
| adjust the timezone settings or the timezone database, the
| time itself is never adjusted.
|
| Unfortunately, using UTC rather than TAI as Unix time's
| foundation is a fatal mistake. As Unix time cannot represent
| leap seconds, all the previous advantages break down - we had
| to freeze or advance the Unix time itself to compensate for
| that limitation. If there's a TAI-based "new Unix time", the
| leap second handling can be simplified a lot. The underlying
| time is always correct regardless of leap seconds. Sure, a
| missed leap second notification makes all civilian time
| faster or slower by 1 second, but the situation is the same
| for UTC if there's no time synchronization.
| toss1 wrote:
| Nice insight on how new systems can lead to apparently
| unrelated discoveries!
|
| I'd like to see not only switching to atomic time, but also to
| UTC globally, which would be far more convenient, but also may
| have it's own set of interesting minor discoveries
| feralimal wrote:
| Why would the earth speed up? Are we going downhill?
| spuz wrote:
| If the average mass of the earth moves from high to low
| elevation then the rotation of the earth will increase in order
| to preserve angular momentum. It's the same physics as an ice
| skater who spins faster when they move their arms close to
| their body.
| tengbretson wrote:
| This is concerning news.
| [deleted]
| lkxijlewlf wrote:
| Maybe it brought its arms in closer.
| beezle wrote:
| The environment of and around the earth is pretty chaotic.
| Think it is way to soon to postulate what caused such a tiny
| variation. How to account for it, different subject.
|
| Odd that I read this first a few days ago via a link to a
| Martha Steward website lol
| jedberg wrote:
| Basically yes. They're saying snow melting is a big cause,
| because it brings that heavy water weight down closer, along
| with erosion and the mountains bringing dirt down closer to the
| center.
| omgwtfbyobbq wrote:
| The GHG/snow angle is really smart. I initially thought that
| petroleum extraction/carbon emissions would slow the planet ever
| so slightly because we're taking stuff from underground and
| moving it into the atmosphere. But water/ice are much heavier,
| and reducing the range of elevations where snow is trapped would
| do the opposite (less water at higher elevations and more at
| lower), plus there's way more snow/water than petroleum.
| anigbrowl wrote:
| If it is validated perhaps advocates for change will be able to
| make the argument that we are literally running out of time and
| it will prove sufficiently engaging that 'skeptics' lose
| traction in trying and failing to refute it. I use scare quotes
| because many self-styled climate skeptics are not sincere
| inquirers after truth but rather shills for established
| economic interests.
| abeppu wrote:
| Or perhaps the established economic interests will astroturf
| some fear about pumped-water hydro systems.
| zarq wrote:
| Petroleum and gasses should be lighter than the rock
| surrounding them right, so if you move those up, the rock above
| those layers will be moved closer to the earth's center. So I
| would expect that that will cause the earth to spin faster, not
| slower.
| omgwtfbyobbq wrote:
| That's a good point, so it could be both. I'm not sure how
| high the average distribution of CO2 would have to be to
| offset that. The petroleum/gas could also be compressed under
| pressure, which might offset that effect to some degree.
| jedberg wrote:
| I don't think a negative leap second would cause much of an issue
| at all. The reason a positive leap second was such a problem was
| because it add an "invalid entry", ie. 23:59:60.
|
| But a negative leap second would just be skipping a valid entry,
| which happens all the time if you're using NTP to set your clock.
|
| Sure, date math libraries would need to updated, but they already
| got updated for the positive leap second to have tables they can
| look up to find out which seconds to add, so adding an entry for
| a skip isn't much different.
|
| Most of the havoc of the positive leap second was in time series
| data having that invalid entry. That won't happen with a negative
| leap second. There just won't be a value there.
| segfaultbuserr wrote:
| > _I don 't think a negative leap second would cause much of an
| issue at all._
|
| But nobody has tested it in the wild. It's entirely possible to
| trigger an existing bug in the code base. I expect some
| disruption from the first negative leap second event. After
| that everything would probably be gradually stabilized.
| throw0101a wrote:
| > _But nobody has tested it in the wild._
|
| The FreeBSD (kernel) folks test their code for it:
|
| > _I run the freebsd kernel and ntpd through "negative" leap
| second events usually a couple times a year as part of
| testing our timekeeping products at $work. I'm skeptical that
| we'll ever see a negative leap, but we have some customers
| who insist on having it demonstrated to them as working
| correctly._
|
| > [...]
|
| * https://lists.freebsd.org/pipermail/freebsd-
| stable/2020-Nove...
|
| Of course then there's userland...
| segfaultbuserr wrote:
| Great, at least we know the kernel is probably good
| (assuming Linux gets tested too and at least the latest
| version doesn't have bugs)... But I still worry about the
| interactions in a complex userspace application can produce
| unexpected outcomes. And I wonder whether Linux previously
| had bugs (too lazy to trace down the git history today),
| and if there was, how many are still in deployment...
| jedberg wrote:
| It's constantly tested in the wild. Every time your computer
| does an NTP update and has to jump ahead one second or more,
| you've just tested it.
| LoSboccacc wrote:
| a skip ahead is different than the officially being at
| 23:59:60, albeit quite many NTP nowaday use leap smearing
| to avoid that https://developers.google.com/time/smear
| throwaway09223 wrote:
| Well, not really. Clock skew is tested, but the code paths
| in adjtimex() for handling a leap second are different.
|
| This is why the 2005 leap second crashed every Linux 2.4
| kernel worldwide as I recall.
|
| Thankfully there's been a push toward leap smear (certainly
| on every system I run) which should obviate this type of
| problem entirely.
| [deleted]
| tiagod wrote:
| Does NTP do that, though? I was under the impression it
| made time slightly faster/slower until the point is met, if
| the difference is small (which it will always be on
| production servers, in principle)
| throwaway09223 wrote:
| ntpd does indeed skip time, contrary to popular belief. I
| didn't believe it myself until one day I studied the
| documentation and code.
|
| Check out the "-x" flag in the manpage.
|
| I recommend dumping ntpd and using chrony instead, and
| also configuring chrony for a time smear rather than the
| leap second as required by the standard.
| segfaultbuserr wrote:
| > _ntpd does indeed skip time_
|
| The documentation also indicates it's rare for a 7x24
| running server to suddenly step time (it only occurs when
| there's a 128 ms difference), unless you get serious
| network congestion that prevents sychroninization for an
| extended period, so a time step in a production server is
| uncommon. But a standard-compliant negative leap second
| _requires_ time stepping, it 's why I said there might be
| disruption.
| throwaway09223 wrote:
| Yes, but the documentation is wrong in its assumption.
| There are many reasons time may skew >128ms beyond
| "network congestion."
|
| I've dealt with datacenters getting a bad ntp config
| push, for example, or a bad firewall ruleset which blocks
| NTP. Fixing the config may inadvertantly step time.
|
| There's a whole host of systems issues, sometimes
| involving VMs and sometimes bare metal which can cause
| this type of problem. The most simple of which is ntpd
| not running properly for a while, but this can also
| happen when systems get overloaded - extreme swapping and
| the like.
|
| ntpd's behavior of non-monotonic time adjustments was
| brought to my attention after a developer uncovered
| database corruption, caused by a database which
| (correctly) assumed that time should be monotonically
| adjusted while the database server was running. I believe
| it mis-ordered a transaction log or something along those
| lines.
|
| There are other, better ntpd implementations like chrony
| which can be configured to never step time. If time needs
| to be stepped, applications should be stopped and the
| machine should be removed from service first.
| segfaultbuserr wrote:
| Thanks for sharing the experience.
|
| > _There are other, better ntpd implementations like
| chrony which can be configured to never step time._
|
| I totally agree that ntpd is worse, it has an aging code
| base with many potential security issues, chrony is a
| better and cleaner implementation. Nevertheless, I refuse
| to refer to "ntpd" as a worse implementation because it
| implemented the leap-second as the standard specified.
| Also, ntpd can be manually configured to never slew time
| (excluding leap second) if -x and -g are used.
|
| > _ntpd 's behavior of non-monotonic time adjustments was
| brought to my attention after a developer uncovered
| database corruption._
|
| BTW, my original topic here is how a negative leap second
| may cause service disruption, ntpd's behavior is only a
| footnote to that discussion. I think your experience only
| strengthened my original argument: if the standard leap
| second implementation (instead of smearing) is used,
| which is the case in a default configuration, _something_
| might happen. But I 'm not sure, a negative leap second
| doesn't break the monotonic assumption. So it's all
| speculations...
| [deleted]
| [deleted]
| segfaultbuserr wrote:
| > _Every time your computer does an NTP update and has to
| jump ahead one second_
|
| PCs don't run anything crucial, usually you can set your
| clock to 2001 without visible problems, the same is not
| true for a server. A server uses ntpd, not a bruce-force
| ntpdate. Under ordinary conditions, ntpd adjusts the clock
| in small steps so that the timescale is effectively
| continuous and without discontinuities. But I think a
| negative leap second is quite violent.
| jedberg wrote:
| I was talking about ntpd. It would do its update after
| the negative leap second and then think to itself "oh,
| I'm more than one second behind now, I better start
| fuzzing and catch up".
| segfaultbuserr wrote:
| It's rare for ntpd to step time forward, unless ntpd lost
| synchronization and the local clock has drifted beyond
| +/- 128 ms by default. On a 7x24 production server, it's
| very unlikely, time is always slewed. But a standard leap
| second implementation _requires_ the addition or deletion
| of time via adjtimex() 's TIME_INS and TIME_DEL, it's not
| adjusted gradually.
|
| > _" oh, I'm more than one second behind now, I better
| start fuzzing and catch up"._
|
| No, ntpd would say, oh, leap second, now it's the time to
| tell kernel to delete a second! And if the kernel's
| negative leap second code path has a bug, kernel panics
| and everything crashes.
|
| ...Yes, you probably can force ntpd to ignore the leap
| second deletion and also force NTP to slew time only.
| This approach is similar to leap second smearing (which
| is considered a violation of standard but nevertheless an
| useful hack). But it requires manual configuration, by
| default the standard approach is used.
|
| So the bottom-line is: Time will be forcefully stepped
| ahead by 1 second (which is an uncommon scenario on
| production server), and, it would not just be an ordinary
| step - it uses the operating systems normally untested
| negative leap second code path. I'm not sure what the
| consequences would be for various services, perhaps not
| much, but my worry is the interactions in a complex
| application can produce unexpected outcomes. Also, how
| many systems have implemented the negative leap second in
| the code path? And are they all tested?
| chungy wrote:
| > The reason a positive leap second was such a problem was
| because it add an "invalid entry", ie. 23:59:60.
|
| It's only a problem if you have a hardcoded assumption that all
| minutes have exactly 60 seconds. You'll encounter the same
| problem if 23:59:58 is followed by 00:00:00
|
| Computers don't usually count time in this manner and the
| display is converted via mathematical formula. It'd just have
| to be adjusted to account for leap seconds, positive or
| negative.
| [deleted]
| anonu wrote:
| I'm not sure why computer scientists really care. Call me a
| naysayer if you like: but why can't we just ignore this problem?
|
| Time as we think of it in computers is an overlay over time in
| the physical world. If they're off by a millisecond will anyone
| notice?
|
| I was a high frequency trader for a long time. The only thing
| that matters in time world is that computers agree on the same
| time. Not that computer time is aligned with real world time.
| amelius wrote:
| Yes. The only ones who will notice the difference are the
| astronomers, who created the problem in the first place (unless
| the time-difference becomes so big that it starts affecting
| perceived daylight times).
|
| On the other hand, it would be great if some authority could
| release a package with time conversion routines that everybody
| could include in their software projects and be done with it.
| However, every language needs its own implementation, which is
| a problem created/not fixed by IT people.
| bioinformatics wrote:
| I think it's global warming. It has to be.
| jandrese wrote:
| I would expect global warming to have the opposite effect.
| Slightly expanding the atmosphere causing the mass to be
| further from the center, slowing down the rotation.
|
| The problem is that the atmosphere is so light compared to the
| rest of the earth that even at the nanosecond level I have
| doubts you would see this effect. To affect the rotation of the
| Earth by whole seconds/year you need to be talking about
| yottatons of rock shifting.
| samatman wrote:
| It could be but it absolutely doesn't have to be.
|
| Heavier material in the mantle subsiding towards the core could
| do it just as easily, and there is _a lot_ more mass beneath
| the crust than above it.
| burlesona wrote:
| I love this quote:
|
| > Scientists also noted that this past summer, on July 19, the
| shortest day ever was recorded--it was _1.4602 milliseconds
| shorter than the standard._
|
| It's so interesting to think about (a) how incredibly stable the
| rotation of the earth in in human terms, and also (b) how far
| we've come to be able to measure something so vast (the rotation
| of our planet) against a scale so tiny (milliseconds - shorter
| than an blink).
|
| The world is amazing :)
| simonh wrote:
| Atomoc clocks are nuts accurate nowadays. They're so good you
| can measure the relativistic gravitational time dilation effect
| of a height difference of a few inches. It takes a while, like
| about a year I think, but you can do it.
| Tommah wrote:
| It's trying to throw us off it.
___________________________________________________________________
(page generated 2021-01-08 23:01 UTC)