2020 Leap Day Bugs
21–30 of 150 posts
Re: 2020 Leap Day Bugs
#22Re: 2020 Leap Day Bugs
#23Random thought: we're now closer to 2038 than to Y2K.
Re: 2020 Leap Day Bugs
#24This 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…
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
#25Random thought: we're now closer to 2038 than to Y2K.
Re: 2020 Leap Day Bugs
#26Random thought: we're now closer to 2038 than to Y2K.
Re: 2020 Leap Day Bugs
#27Earlier 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.
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
#28This 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…
Re: 2020 Leap Day Bugs
#29Random 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