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

111–120 of 150 posts

Re: 2020 Leap Day Bugs

#111

Post by wahern »

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.

More specifically, POSIX explicitly defines a day as having precisely 86400 seconds. This makes calendar arithmetic trivial, including into the future, which would otherwise be impossible as leap seconds aren't predictable. Any program with a leap day bug is almost certainly not making use of Unix timestamps.

The corollary is that for the most commonly used APIs a Unix second isn't the same thing as an SI second. A Unix second is effectively defined in terms of the civil calendar, not as a fixed quantum of physical time.

Technically this doesn't preclude Unix date-time strings from displaying a 60th second. (And maybe some do.) But it would require unnecessary extra work, introduce inconsistencies (i.e. a generated string for a future date-time that happened to be a leap second would show :59 today but :60 at the moment of the leap second), and invite bugs.

Re: 2020 Leap Day Bugs

#112

Post by macintux »

perl4ever wrote: post #105
gmueckl wrote: post #75

Earlier quoted context omitted.

Let's not forget events spanning time zones. Just some random thing that came to my mind: how would you handle calendar entries where half the participants made a DST transition since the entry was created and the other half didn't? This happens for example when half of the team is in the US and the other half in the EU. The transition dates are a week apart.

I remember seeing a thick dead tree type of book with the history of time zones in the US, for figuring out times in historical documents when things were less standardized. It was practically the size of a phone book; I think it probably covered county level history or something like that.

I have a book covering, among other things, Indiana time zones for a few years during IIRC the 1960s.

It’s frankly amazing how much they changed every year. Different counties, and sometimes towns/cities within counties, would jump back and forth year to year. It would have been awful to manage if computers had been more important at that time.

Re: 2020 Leap Day Bugs

#113

Post by macintux »

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.

I do wonder whether the fact that some systems aren’t really 4-digit-year compliant is making this uglier this year. I know Splunk got hit with a 2020 bug.

Re: 2020 Leap Day Bugs

#114

Post by onei »

kevin_thibedeau wrote: post #102
onei wrote: post #29

Earlier quoted context omitted.

If you store time as seconds since the Unix epoch (1st Jan 1970), you'll overflow a 32 bit unsigned integer in 2038 (around March iirc) and time will suddenly be back in 1970 again. I believe the Linux kernel did some work to circumvent this on 32 bit systems in a recent release, but if you're running an old 32 bit system you're probably out of luck.

Related is NTP which overflows in 2036 because it uses unsigned 32-bit seconds since 1900.

That's technically correct, but NTPv4 has the concept of eras [1] which gets incremented when that number would normally wrap.

[1] https://tools.ietf.org/html/rfc5905#section-6

Re: 2020 Leap Day Bugs

#115

Post by onei »

FreeFull wrote: post #34
onei wrote: post #29

Earlier quoted context omitted.

If you store time as seconds since the Unix epoch (1st Jan 1970), you'll overflow a 32 bit unsigned integer in 2038 (around March iirc) and time will suddenly be back in 1970 again. I believe the Linux kernel did some work to circumvent this on 32 bit systems in a recent release, but if you're running an old 32 bit system you're probably out of luck.

Actually, it's signed 32-bit integers that overflow in 2038. Signed integers have been used because people wanted to store dates earlier than 1970 too.

Ah yes, thanks for the correction :)

Re: 2020 Leap Day Bugs

#116

Post by henriquemaia »

swypych wrote: post #110
kclay wrote: post #91

Earlier quoted context omitted.

I have an old Zune. Going give this a try this year

For the lazy https://www.theguardian.com/technology/blog/2009/jan/01/zune...

Well... thanks. But not because I'm lazy, for I had no idea about this bug there. I just thought OP had an off topic moment based on random connection.

But now, after reading your link and giving it a bit of thought, what s/he wrote makes perfect sense even without your link.

So... thanks.

Re: 2020 Leap Day Bugs

#117

Post by GolDDranks »

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

That good reason is that there is no general "formula" for leap seconds, unlike for leap years, they have to be looked up. So you can't do "offline" date calculations if they included leap seconds.

I think that UNIX time stamps are generally a very good approximation, and if you are comparing long enough time intervals for the error to get over one second, and/or that error to matter, you are doing something wrong anyway.

For exact time interval measurements that you have to get exactly right, don't use UNIX time stamps.

Re: 2020 Leap Day Bugs

#118

Post by PopeDotNinja »

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

Immediately thought of Tom Scott's Computerphile video on time & timezones:

https://youtu.be/-5wpm-gesOY

10m12s watch. Informative and entertaining.

Re: 2020 Leap Day Bugs

#119

Post by thaumasiotes »

adrianmonk wrote: post #43
FreeFull wrote: post #34

Earlier quoted context omitted.

Actually, it's signed 32-bit integers that overflow in 2038. Signed integers have been used because people wanted to store dates earlier than 1970 too.

And probably because signed integers are a default choice in certain languages and/or maybe on certain architectures. Java, for example, famously doesn't even have an unsigned 32-bit integer primitive type. (But it has library functions you can use to treat signed integers as unsigned.) Ultimately not a good design choice, but the fact that it actually wasn't that limiting and relatively few people care or notice tel…

> Ultimately not a good design choice, but the fact that it actually wasn't that limiting and relatively few people care or notice

It was a horrific design choice, and people do notice and do hate it.

Not so much because of how it applies to ints, but because the design choice Java made was to not support any unsigned integer types. So the byte type is signed, conveniently offering you a range of values from -128 to 127. Try comparing a byte to the literal 0xA0. Try initializing a byte to 0xA0!

In contrast, C# more sensibly offers the types int / uint, short / ushort, long / ulong, and byte / sbyte.

Re: 2020 Leap Day Bugs

#120

Post by system2 »

Considering billions of devices and services not being affected, these bugs are very insignificant. At least we figured out leap day bugs and not having y2k crisis' every four years.
Post reply on HN