 | | Re: CGI question
|
| (...) I had a C programming class in college with this woman who was upset that "MOVE TO" and "MULTIPLY BY" weren't part of the C language. The moment she said that, an eerie silence fell over the classroom... The punchline is that two years later, (...) (25 years ago, 7-Apr-00, to lugnet.off-topic.geek)
| | | | | Re: CGI question
|
| (...) Scary bit of COBOL code one of my co-workers ran across today (he was given the code because it's the closest thing to documentation available for a file he has to deal with): IF FLD_XYZ_YR < 29 THEN FLD_XYZ_YR4 = 2000 + FLD_XYZ_YR4 ELSE (...) (25 years ago, 8-Apr-00, to lugnet.off-topic.geek)
| | | | | Re: CGI question
|
| (...) Sure. That's a pretty typical Y2K fix. And it's basically what you do as a human when looking at a two-digit year. (If I tell you that the expiration date on my driver's license is 12-30-02, you assume 2002. If I tell you it's 12-30-98, you (...) (25 years ago, 8-Apr-00, to lugnet.off-topic.geek)
| | | | | Re: CGI question
|
| (...) Yeah, the windowing/epoching/whatevering isn't a big deal. The thing is, they *hardcoded* the 29. They didn't even make it a constant, defined at the top of the code (or in a copybook). So in some number of years, someone is going to have to (...) (25 years ago, 10-Apr-00, to lugnet.off-topic.geek)
| | | | | Re: CGI question
|
| (...) Oh, but no one will *possibly* be using the same code in 29 years. We don't need to worry about that. *much laughter* The unix epoch rollover is gonna be another one.... (25 years ago, 10-Apr-00, to lugnet.off-topic.geek)
| | | | | Re: CGI question
|
| (...) at least at the unix epoch, most of the code won't have to be changed - the assumption here is that we won't be using 32-bit boxes anymore, so a long int will be a lot longer :) :) Dan (25 years ago, 10-Apr-00, to lugnet.off-topic.geek)
| | | | | Re: CGI question
|
| (...) In core, yah, but wot about in packed data structs on tapes? --Todd (25 years ago, 10-Apr-00, to lugnet.off-topic.geek)
| |
