[HN Gopher] Ask HN: How is it that programmers can simply ignore...
___________________________________________________________________
Ask HN: How is it that programmers can simply ignore leap seconds?
I am an professional software developer, and have occasionally
needed to work with dates and times, including applications that
require a certain level of accuracy (e.g. processing pricing feeds
from financial institutions) Since 1970, there have been 27 leap
seconds applied. But these don't show up anywhere in any computer
system I have ever used (OS, languages, applications, third party
APIs). If I create a date object of 1970-01-01T00:00:00 and
repeatedly add 86400 seconds, should I not end up with a date/time
that is no longer midnight? I assume that we are collectively just
ignoring leap seconds and hoping for the best. Is this OK?
Author : sporkle-feet
Score : 10 points
Date : 2022-01-14 22:24 UTC (36 minutes ago)
| dexwiz wrote:
| Computers usually report time in UTC. Most computers are pretty
| bad at keeping time, and regularly sync to NTP servers for the
| current time. NTP servers generally have better time keeping
| hardware (or sync with better sources). When a leap second
| occurs, NTP servers will smear that second over 12 hours or so.
| Different NPT servers have different smear standards. During that
| smear, seconds are a bit longer, or shorter for negative leap
| seconds, than usual. But for general computing this doesn't
| matter. The smear is on a similar order of magnitude of normal
| clock drift. This isolates the leap second to only computers that
| need to track it. UTC/UT1 is designed to be used by humans and is
| based on the Earth's revolution and rotation about the sun (well
| now it's actually measured using distant pulsars).
|
| The big reason to isolate this is because leap seconds aren't
| totally determinate. We can predict them to some degree, but
| ultimately rely on measurement. Unlike something like leap days,
| you cannot safely code a system that accounts for future leap
| seconds. Leap days follow a well-defined formula, leap seconds do
| not.
|
| For time sensitive applications like navigational computers, TAI
| is used. TAI is currently 37 seconds off from UTC. TAI is
| associated with the SI Second unit. While originally derived from
| the solar day, it is now based on the vibrational frequency of a
| caesium atom.
|
| For a more detailed explanation see
| http://mperdikeas.github.io/utc-vs-ut1-time.html for a good
| summary.
|
| For an overview on how Google handles the smear see
| https://developers.google.com/time/smear
| cirwin wrote:
| A failure rate of ~once every two years is so tiny compared to
| the rate of failure introduced by other things (from human error,
| on up); and for many time-related things being off by a second is
| irrelevant (or again tiny compared to all the other sources of
| noise in measuring time). So it seems reasonable to me to ignore
| leap seconds in the vast majority of projects.
|
| That said, modern cloud environments do hide this problem for you
| with leap smearing [1], which seems like the ideal fix. It'd be
| nice to see the world move to smeared time by default so that
| one-day = 86400 seconds stays consistent (as does 1 second = 10e9
| nano-seconds); but the length of the smallest subdivisions of
| time perceived by your computer varies intentionally as well as
| randomly.
|
| [1] https://developers.google.com/time/smear
| theandrewbailey wrote:
| I've always wondered that, too. There are fields where exact
| second level precision is required, but virtually everyone is OK
| with systems being up to a few seconds off here and there.
| kaesar14 wrote:
| It could be the case that as long as dates are internally
| consistent (a timestamp for an object created later than
| another reflects that fact) most systems wont break.
| themerone wrote:
| Leap seconds aren't a precision issue unless you need to
| calculate time delta's between events.
| mikewarot wrote:
| I've never worked on systems that required absolute timing
| accuracy to more than a few minutes. The only date/times were
| timestamps on human activity, on computer sets by a humans, not
| NTP.
| themerone wrote:
| Most of us don't need to hope for the best because leap seconds
| won't trigger bugs in our applications.
|
| In my work, I deal with dates and times, but a leap second would
| have no consequence. A negative leap second would be interesting,
| because database records could appear to have been created out of
| order (a possible problem for many apps), but my apps wouldn't
| care.
|
| There are programmers that have to worry about leap seconds, I'm
| happy I'm not one of them.
___________________________________________________________________
(page generated 2022-01-14 23:01 UTC)