Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2020 Leap Day Bugs

codeofmatt.com

Post reply on HN
Print view View original

81–90 of 150 posts

Re: 2020 Leap Day Bugs

#81

Post by LukeShu »

twic wrote: post #59
codetrotter wrote: post #42

Earlier quoted context omitted.

> Suddenly the time runs backwards It is my understanding that the way NTP deamons work is that time is never adjusted backward. Instead, the ticks are "slowed down" on the local machine until it is in sync with the NTP time. However, if the difference is too great then I think NTP deamons might refuse to correct the time all together. So then, if my understanding is correct, your machine is "stuck in the future". Bu…

My understanding (i am also not an expert!) is that common NTP implementations will do the slowing down ("slewing") to correct small errors, but will just change the time ("stepping") to correct large errors. It will even do this if that means time going backwards. Subject to configuration, of course. man ntpd [1] says: > Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on…

timesyncd also does this for "large offsets", but what "large" is is neither configurable nor documented, but in the source:

    /*
     * Maximum delta in seconds which the system clock is gradually adjusted
     * (slewed) to approach the network time. Deltas larger that this are set by
     * letting the system time jump. The kernel's limit for adjtime is 0.5s.
     */
    #define NTP_MAX_ADJUST                  0.4

Re: 2020 Leap Day Bugs

#82

Post by mortehu »

Misdicorl wrote: post #31
burfog wrote: post #24

Earlier quoted context omitted.

You can still have problems. It may be determined that the computer's clock got too far ahead. For example, it booted and you cared about time, but NTP hadn't yet made corrections. Suddenly the time runs backwards. Leap seconds may get interesting too, especially if you have to predict ahead or if the OS isn't updated often enough. (there is a 6-month warning) If you want to call leap seconds an issue for humans, the…

Leap seconds are only a problem for wall clocks (localization) and deciding whether to call something utc or tai. The ntp case is contrived. Either you care and wait until ntp has connected to do your stuff. Or you care and don't let ntp rewind and instead smear. Or you don't care and deal with the consequences.

Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". You can't measure the length of time intervals spanning leap seconds with simple subtraction.

Re: 2020 Leap Day Bugs

#83

Post by fao_ »

LukeShu wrote: post #81
twic wrote: post #59

Earlier quoted context omitted.

My understanding (i am also not an expert!) is that common NTP implementations will do the slowing down ("slewing") to correct small errors, but will just change the time ("stepping") to correct large errors. It will even do this if that means time going backwards. Subject to configuration, of course. man ntpd [1] says: > Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on…

timesyncd also does this for "large offsets", but what "large" is is neither configurable nor documented, but in the source: /* * Maximum delta in seconds which the system clock is gradually adjusted * (slewed) to approach the network time. Deltas larger that this are set by * letting the system time jump. The kernel's limit for adjtime is 0.5s. */ #define NTP_MAX_ADJUST 0.4

> neither configurable nor documented, but in the source:

Build it yourself and pass -DNTP_MAX_ADJUST=XX

Re: 2020 Leap Day Bugs

#84

Post by Misdicorl »

mortehu wrote: post #82
Misdicorl wrote: post #31

Earlier quoted context omitted.

Leap seconds are only a problem for wall clocks (localization) and deciding whether to call something utc or tai. The ntp case is contrived. Either you care and wait until ntp has connected to do your stuff. Or you care and don't let ntp rewind and instead smear. Or you don't care and deal with the consequences.

Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". You can't measure the length of time intervals spanning leap seconds with simple subtraction.

Are they truly? There must be a good reason but I can't fathom what it could be

Re: 2020 Leap Day Bugs

#85

Post by Misdicorl »

nradov wrote: post #63
mytailorisrich wrote: post #39

Earlier quoted context omitted.

I've come to the same conclusion as you: Keep time as a purely monotonic integer for everything and convert that as needed to display to humans. This also pushes all the madness to the edges and out of the business logic. That being said, this works well for applications that are not "date intensive" so to speak. If your business logic has to deal specifically with calendar dates, e.g., monthly events, then you have…

The monotonic integer approach doesn't work for most healthcare applications. Due to safety and compliance requirements we typically need to record both the local time and the zone offset which applied at that instant.

This is surprising for event recording since they should be equivalent but time + zone is strictly more likely to be messed up. E.g 2:30 a.m. is two times during daylight changeover so you must correctly specify est or edt.

Re: 2020 Leap Day Bugs

#86

Post by klingonopera »

marcosdumay wrote: post #74
anonsivalley652 wrote: post #10

Stupid Q: Why doesn't the syslog protocol (RFC5424) deal with leap seconds (the seconds field goes to 00-59, not 00-60)? Are they using UTC (they would have to ignore LS and have crappier logs) or TAI (doesn't have LS)? https://mailarchive.ietf.org/arch/msg/syslog/DDLgKsRPITFXYSB... http://www.madore.org/~david/computers/unix-leap-seconds.htm... https://tools.ietf.org/html/rfc5424 https://cr.yp.to/libtai/tai64.html h…

Unix systems usually do not have extra seconds after 23:59:59. Leap seconds are normally dealt with by slowing your clock down. So Unixes use neither UTC or TAI, they use something else. It's something that does not matter in 99.99% of the cases, and that other 00.01% need specialized hardware and software for dealing with it anyway.

Precisely, get yourself five digital devices that track time, and see how many of them are even accurate to the second. Probably none of them. But implementation of leap seconds would only make sense on systems that at least fulfill that minimum criteria.

Leap seconds are things for stock market servers, atom clocks, scientific devices and the like.

Re: 2020 Leap Day Bugs

#87

Post by a3n »

tech234a wrote: post #22

My Timex Expedition watch also skipped to March 1.

Timex Ironman bought within the last two years, almost certainly less than $20, says 3/1 Sat today. The numbers on the back might say "029 36". Or maybe "029 56". I'm sure its innards are the same as most of the other sub-$20 Ironmans.

Re: 2020 Leap Day Bugs

#88

Post by heartbeats »

Misdicorl wrote: post #84
mortehu wrote: post #82

Earlier quoted context omitted.

Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". You can't measure the length of time intervals spanning leap seconds with simple subtraction.

Are they truly? There must be a good reason but I can't fathom what it could be

Because otherwise you would get annoying off-by-27 errors whenever you did time() % 60.

https://en.wikipedia.org/wiki/Leap_second#Binary_representat...

Re: 2020 Leap Day Bugs

#89

Post by earthboundkid »

Misdicorl wrote: post #16
hmate9 wrote: post #2

This is why no one should ever ever write their own Time or Date library. The number of edge cases is simply enormous

Almost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for hum…

> Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch.

You poor sweet summer child. Has no one told you about the leap seconds yet? Unix time is not the number of seconds since epoch. It deliberately excludes leap seconds, which happen unpredictably whenever scientists measure the Earth as having spun at a different enough speed for long enough.

Time is fucked on every level:

- Philosophical: What is time? We just don't know.

- Physical: Turns out there is no such thing as simultaneity, and time flows differently at different locations. Time may be discrete at the Planck level, but we don't really know yet.

- Cosmological: The Earth does not rotate at a constant speed, the Earth does not orbit the Sun at a fractional component of its rotation, and the Moon does not orbit at even ratio either.

- Historical: Humans have not used time or calendars consistently.

- Notational: Some time notations are ambiguous (e.g. during daylight savings transitions) and others are skipped.

- Regional: Different regions use subtly different clocks and calendars.

- Political: Different political actors choose to change time whenever they feel like it with little or no warning.

- Religious: Many religions come with their own system for timekeeping, and people don't like when outsiders impose other systems.

Re: 2020 Leap Day Bugs

#90

Post by stOneskull »

Yessing wrote: post #56

is there something special about 2020 (regarding leap years)? the rule I know is divisible by 4 && ( not divisible by 100 || divisible by 400) so 2020 is not even an edge case.

Over 4 years there are a lot more apps and a lot more reliance on apps. There's lots more spaghetti out there since 2016 so more likelihood of bugs. I assume 2024 will have more.
Post reply on HN