3 ms·
> Bugs based on a time calculations can often show themselves later when view through a longer lens and scope of time...sometimes WAY longer than you'd expect.
by macintux 5y ago
> Bugs based on a time calculations can often show themselves later when view through a longer lens and scope of time...sometimes WAY longer than you'd expect.
When I worked for BBN in '97-'98, someone from outside the company as I recall came to talk to a room of engineers about the wide variety of calendar-related behaviors in various UNIX systems that were expected to cause problems for Y2K.
It was a very, very long list, often subtle issues, and I recall the concern in the room about the number of old systems in use by the DoD and others.
Anyway, no real point to this other than date handling is one of the hardest things to get right in computing, ranking right behind testing for the correct behavior.
- RegBarclay 5y agoDates are a pain. The date bug I committed with the longest tail was daylight time. It was all good until we got to a day with 25 hours when we "fell back."
- Jiro 5y agoI had one of those on my Pebble: https://github.com/mattrossman/forecaswatch2/issues/44 https://github.com/mattrossman/forecaswatch2/issues/44
- DougN7 5y agoYou are most definitely not alone with that exact bug. Welcome to the club! :)
- randomswede 5y agoBe happy you didn't have to deal with week numbers. IIRC, a Norwegian bank ended up having an outage because part of the code could not cope with the 53rd week in a year.