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

71–80 of 150 posts

Re: 2020 Leap Day Bugs

#71

Post by mercora »

huh! i just noticed few hours ago a pi i use has had the wrong date which was set to a day earlier. I quickly determined a faulty ntp server i had hard configured was giving the bogus time. In case it is of interest its address was "144.76.60.190" and was chosen by random chance because i cant resolve names without working time on that machine (don't ask). It appears to be taken offline by now though but i checked its giving the wrong time before changing to another server.

Also, but probably unrelated, my WiFi stopped working exactly 00:00AM CET but that might be unrelated as it does that all the time :)

Re: 2020 Leap Day Bugs

#72

Post by marcosdumay »

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.

Leap days are an edge case by themselves, it doesn't need any extra thing special about it.

Re: 2020 Leap Day Bugs

#73

Post by jrandm »

maxerickson wrote: post #27
jrandm wrote: post #20

Earlier quoted context omitted.

I believe accurately conveying identical information in a manner everyone can understand is an impossible, or at least unreasonable, burden to place on individuals. Instead, what if people tried to hear graciously and "assume good faith"? The quote is ripped from HN's guidelines.

Can you please explain more about how your response relates to my comment? For instance, I've not placed the burden of "conveying identical information in a manner everyone can understand" on anyone, nor have I assumed bad faith. So it seems like a weird comment to tack onto mine, but I am assuming I just don't correctly understand.

The sibling replies by IggleSniggle I fully endorse as supporting my meaning in the original post.

As to explaining more about my thought process: You asked a hypothetical "what if" question which, given the question itself is imprecise, I interpreted as you wishing information was always conveyed to your desired precision/accuracy, and extrapolated that (given this is a public forum) into general communication.

I shared my thoughts, specifically that it seems impossible for a person to always communicate perfectly to an unknown audience, and offered a different hypothetical. The last line explains the punctuation use in my "what if."

Re: 2020 Leap Day Bugs

#74

Post by marcosdumay »

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.

Re: 2020 Leap Day Bugs

#75

Post by gmueckl »

nitwit005 wrote: post #67
Misdicorl wrote: post #16

Earlier quoted context omitted.

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…

It depends on the purpose of the app, but you often have to store user entered times with time zone information. The rules for things like daylight savings time can and do change, and you don't want future scheduled events drifting by an hour.

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.

Re: 2020 Leap Day Bugs

#76

Post by cgriswald »

Aeolun wrote: post #44
ehsankia wrote: post #40

Earlier quoted context omitted.

It's not only about writing your own library though. For example, it's often not reading the documentation properly. In Python, if you take a datetime, and call .replace(year=X) on a datetime for Feb29, it'll throw a ValueError.

Even if you replace it with another leap year?

It returns a new datetime object which includes its own validity check and raises an exception for a bad leap day the same way it would for March 32nd or Blurnsuary 12th. (However, year must be an integer in [1, 9999].)

Edit: So, another leap year would be fine.

Re: 2020 Leap Day Bugs

#77

Post by Misdicorl »

ajnin wrote: post #46
Misdicorl wrote: post #16

Earlier quoted context omitted.

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…

You're assuming a source of monotonic nanotime is easy to get and will always be available. This is not the case. As far as I know you have either "wall time" as usually defined, with all the problems associated with clock drift, NTP syncs, computer going into sleep mode, etc, or "nanotime" which is some time delta from some arbitrary reference and which can only be used to compute time differences and not arbitrary…

You use the arbitrary reference and sample the wall clock a couple times to interpolate a best effort offset from utc 0.

If you care more than this, you'll be displeased with off the shelf solutions too

Re: 2020 Leap Day Bugs

#78

Post by Misdicorl »

nitwit005 wrote: post #67
Misdicorl wrote: post #16

Earlier quoted context omitted.

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…

It depends on the purpose of the app, but you often have to store user entered times with time zone information. The rules for things like daylight savings time can and do change, and you don't want future scheduled events drifting by an hour.

Yes, as I said above, if you need to localize then you'll need more detail.

Re: 2020 Leap Day Bugs

#79

Post by Misdicorl »

gmueckl wrote: post #75
nitwit005 wrote: post #67

Earlier quoted context omitted.

It depends on the purpose of the app, but you often have to store user entered times with time zone information. The rules for things like daylight savings time can and do change, and you don't want future scheduled events drifting by an hour.

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.

None of these edge cases are solved by using off the shelf libraries instead of running your own.

Re: 2020 Leap Day Bugs

#80

Post by scarmig »

tzs wrote: post #68

Sears appears to have have taken this to a new level. I got two emails from them today. The first arrived at 6:36 AM, with subject > Confirmed! Your mystery Leap Year offer awaits inside. How much will you save? The second arrived at 9:54 AM, with subject > Oops! Your code is fixed. (We shoulda looked before we leap-yeared...) The messages themselves appear to be identical except for some query parameters on some URL…

Botching is pretty ungenerous. All of the above can easily happen in the context of a complicated software system.

Experienced people who avoid these issues are mostly experienced with smashing headfirst into one of these tricky areas and approaching them with an attitude of "here be dragons" afterwards. One bitten, twice shy.

Post reply on HN