Random thought: we're now closer to 2038 than to Y2K.
2020 Leap Day Bugs
11–20 of 150 posts
Re: 2020 Leap Day Bugs
#12This is why no one should ever ever write their own Time or Date library. The number of edge cases is simply enormous
Ask Jon Skeet: https://blog.nodatime.org/2011/08/what-wrong-with-datetime-a...
When you encounter someone saying "no one should ever", you can substitute "fewer than a half dozen groups of people should tackle this problem (in systems they want to use in production). It will take each such group a tremendous number of hours, involving a multi-year process of slowly finding edge cases and missing functionality."
If that's not true, then there's room to complain, but dates and times fit the bill. In some ways they're worse than other "harder" problems, because people are more likely to think those harder problems are too hard for them. And while the vast majority of companies don't need a proprietary database, it's more likely to be a competitive advantage than your own datetime library.
I think I could eventually write a good datetime library. But I certainly should not, unless I decide that's going to be one of my major efforts to help a language that doesn't already have one.
Re: 2020 Leap Day Bugs
#13I haven't been able to figure out if this is a Google issue or King County Metro issue yet, but google maps transit directions are completely broken today. Every suggestion is "take Lyft" or wait until 4 am tomorrow.
Re: 2020 Leap Day Bugs
#14Stupid 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…
Is there a real need for syslog to handle leap seconds? As that email you linked to points out, most implementations are likely to screw it up to some extent; requiring everyone to ignore leap seconds seems to narrow the range of possible behaviors. It also strikes me that syslog timestamps aren't something you should be depending on too heavily in the first place, especially not for things like calculating precise time durations between separate messages.
Re: 2020 Leap Day Bugs
#15Random thought: we're now closer to 2038 than to Y2K.
and only heading in that direction
Re: 2020 Leap Day Bugs
#16This 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 humans or have something happen at a particular time in a particular timezone, things get gross. But that's no different than any other situation where you eventually have to interface machine data with humans. Either it's your particular expertise or it's a distraction and you should use someone else's solution.
Re: 2020 Leap Day Bugs
#17Earlier quoted context omitted.
Ask Jon Skeet: https://blog.nodatime.org/2011/08/what-wrong-with-datetime-a...
When you encounter someone saying "no one should ever", you can substitute "fewer than a half dozen groups of people should tackle this problem (in systems they want to use in production). It will take each such group a tremendous number of hours, involving a multi-year process of slowly finding edge cases and missing functionality." If that's not true, then there's room to complain, but dates and times fit the bill.…
What if people tried to speak precisely for effect instead of hyperbolically for emphasis?
Re: 2020 Leap Day Bugs
#18Let's not forget the stuff that'll break December 31, 2020... because it'll be day 366 (or 365, if 0-indexed).
Anyone still using a Zune out there?
Re: 2020 Leap Day Bugs
#19The bulk of our deployed Yealink T56 phones displayed February calendar events for the wrong day. I never did find out why.
Re: 2020 Leap Day Bugs
#20Earlier quoted context omitted.
When you encounter someone saying "no one should ever", you can substitute "fewer than a half dozen groups of people should tackle this problem (in systems they want to use in production). It will take each such group a tremendous number of hours, involving a multi-year process of slowly finding edge cases and missing functionality." If that's not true, then there's room to complain, but dates and times fit the bill.…
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.