4 ms·
The place where I worked at the time was already all UNIX/Linux so our Y2K was 2038. We just needed to adjust a few printed reports and client-side birth date h
by alisonatwork 3y ago
The place where I worked at the time was already all UNIX/Linux so our Y2K was 2038. We just needed to adjust a few printed reports and client-side birth date heuristics to make everything work fine.
Until February 29, 2000. Then several of our customers' systems messed up. I seem to recall it was a problem with SCO OpenServer and that our Red Hat customers didn't have any issues, but I might be misremembering. Either way, for whatever reason the leap year was not recognized on one of the system or application layers, and that mismatch caused bigger problems than any 1900/2000 client-side confusion would've done.
- Tor3 3y agoUnix/Linux or not didn't matter for Y2K, the problems were in software elsewhere and that was as major in Unix/Linux as anywhere else (the systems I was fixing at the time were based on both Unix and Linux). (When I was way younger I ran into a software problem where the company providing the software did all date calculations by adding up dates, months, years and.. not getting it right. Between Christmas and New Year something bad always happened. I was working night shifts at the time, and the software was part of locating emergency transmitters, mainly at sea.. when those systems went down it was pretty critical. The first thing I mandated when I got any say in things back then was that all time calculations should be done by adding up seconds.. not dates. Oh well. Fun times)
- netsharc 3y agoThe leap year law translated to English doesn't just say "Every year divisible by 4 has a leap day.", it also says, "Unless the year is divisible by 100, then it's not a leap year". But then it also says "But if it's divisible by 400, it's a leap year again!" So maybe some of the programmers only knew the first 2 rules...