Live data from Hacker News

2020 Leap Day Bugs

codeofmatt.com

21–30 of 150 posts

Re: 2020 Leap Day Bugs

#23
post #11

Random thought: we're now closer to 2038 than to Y2K.

what does this mean? you're okay if you're using 64bits? just briefly skimmed the 2038 wikipedia page, mentioned 32bit

Re: 2020 Leap Day Bugs

#24
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…

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, then you aren't using UTC at all. You're using TAI. Software interfaces often ignore the distinction between UTC and TAI, and even between UTC and UT1, preferring to pretend these issues don't exist. POSIX is in conflict with international timekeeping, effectively requiring that there are zero leap seconds.

Re: 2020 Leap Day Bugs

#26
post #11

Random thought: we're now closer to 2038 than to Y2K.

It's already here...I saw an issue a few weeks ago a bunch of production systems failed upon seeing a certificate signed by a CA root that expires after 2038.

Re: 2020 Leap Day Bugs

#27
post #20

Earlier quoted context omitted.

What if people tried to speak precisely for effect instead of hyperbolically for emphasis?

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.

Re: 2020 Leap Day Bugs

#28
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…

Your percentages are backwards, IME. Timeouts and logging and such are definitely not “80% of use cases”. Interfacing with humans and human systems are.

Re: 2020 Leap Day Bugs

#29
post #23
post #11

Random thought: we're now closer to 2038 than to Y2K.

what does this mean? you're okay if you're using 64bits? just briefly skimmed the 2038 wikipedia page, mentioned 32bit

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.
Post reply on HN