Hercules
Temporal Navigator
There is some other reason we should think about- Why he went to 1998 instead of going to 2000 directly? What promise he made to his Grandfather while he knows that he and his family are not gonna die in the disaster, the civil war and the nuclear war?
There is one possibility- JT's father was selling oranges. So he was not a very Rich man. JT made a promise to his Grandfather to make his father rich and send his family to a safe part of the World- out of US. How he made them Rich? By smuggling the IBM 5100s(Legacy Code) and selling it in 1998 to easily fix the Y2K, moving to 2000 as a Very Rich Man- made his Family Rich...
He used the word "screwed" because he screwed the Y2K programmers.
"Finally, the much expected date 01 January 2000 arrived and departed with nothing more than minor glitches and absolutely no catastrophes.
Their corporate data secured and safe, companies with legacy systems sighed relief and announced the end of the Y2K party."
http://www.theindianprogrammer.com/issues/post_Y2K.htm
Just google "Legacy Code+Y2K"
"Let’s examine why it appears that many of us experts were so far off in our predictions. One of the perplexing problems we had in predicting events is that the Year 2000 issue covered such a broad spectrum of events and scientific disciplines. It was a problem of old and clunky legacy code that runs our payrolls and other financial and manufacturing systems. Frequently written in COBOL, a programming language first introduced in the sixties, it was at first thought to be the full extent of the Year 2000 problem. Most of the old legacy systems used only two digits to represent the year, and any place where dates were computed, sequenced, or compared, our old date shorthand code had to be changed. For the most part this was done with either "windowing" or date expansion. Windowing is merely an inference or "guessing" of the century based on what the year is. For example, if the year was 50 through 99, it was frequently assumed the year should be prefixed with the digits of 19. And if the year was 0 through 49, it was assumed the year should be prefixed with the digits of 20. The problem was that not everyone used the same rules. This makes sharing of information (as in electronic data interchange, or EDI for short), somewhat of a risky venture. Date expansion was generally considered the "best practice" method, but for a variety of cost and resource reasons, was not always the method chosen. There were also other, lesser-known methods as well."
http://www.russkelly.com/y2kwinnersandlosers.html
"Regardless of how the Y2K issue is viewed, modified code should be tested, and unmodified parts of the system should be retested to ensure that each "fixed" system is Y2K immune. As already stated, these testing expenses can be pricey. One reason is that few testing tools are smart enough to automatically know how to minimize testing costs for modified code. However, you would think a "smart" tool could determine exactly what code needed to be retested. It would be great if such an automated tool existed to distinguish that kind of code in a "optimized" mode, i.e., determine the least amount of code that needed to be retested to demonstrate that a code conversion was correct."
Unfortunately, no such tool exists. This suggests that there is a serious need for tools that seamlessly integrate with Y2K conversion tools and that test Y2K conversions. If such tools existed, the total global cost of the Y2K problem could be reduced while still providing sufficient confidence that Y2K conversions were correct. This could add up to astronomical savings, as the world-wide cost for fixes alone is $600 billion, not to mention legal liability costs that could exceed $1 trillion [2, 3].
http://www.stsc.hill.af.mil/crosstalk/1998/01/y2kfixes.asp
There is one possibility- JT's father was selling oranges. So he was not a very Rich man. JT made a promise to his Grandfather to make his father rich and send his family to a safe part of the World- out of US. How he made them Rich? By smuggling the IBM 5100s(Legacy Code) and selling it in 1998 to easily fix the Y2K, moving to 2000 as a Very Rich Man- made his Family Rich...
He used the word "screwed" because he screwed the Y2K programmers.
"Finally, the much expected date 01 January 2000 arrived and departed with nothing more than minor glitches and absolutely no catastrophes.
Their corporate data secured and safe, companies with legacy systems sighed relief and announced the end of the Y2K party."
http://www.theindianprogrammer.com/issues/post_Y2K.htm
Just google "Legacy Code+Y2K"
"Let’s examine why it appears that many of us experts were so far off in our predictions. One of the perplexing problems we had in predicting events is that the Year 2000 issue covered such a broad spectrum of events and scientific disciplines. It was a problem of old and clunky legacy code that runs our payrolls and other financial and manufacturing systems. Frequently written in COBOL, a programming language first introduced in the sixties, it was at first thought to be the full extent of the Year 2000 problem. Most of the old legacy systems used only two digits to represent the year, and any place where dates were computed, sequenced, or compared, our old date shorthand code had to be changed. For the most part this was done with either "windowing" or date expansion. Windowing is merely an inference or "guessing" of the century based on what the year is. For example, if the year was 50 through 99, it was frequently assumed the year should be prefixed with the digits of 19. And if the year was 0 through 49, it was assumed the year should be prefixed with the digits of 20. The problem was that not everyone used the same rules. This makes sharing of information (as in electronic data interchange, or EDI for short), somewhat of a risky venture. Date expansion was generally considered the "best practice" method, but for a variety of cost and resource reasons, was not always the method chosen. There were also other, lesser-known methods as well."
http://www.russkelly.com/y2kwinnersandlosers.html
"Regardless of how the Y2K issue is viewed, modified code should be tested, and unmodified parts of the system should be retested to ensure that each "fixed" system is Y2K immune. As already stated, these testing expenses can be pricey. One reason is that few testing tools are smart enough to automatically know how to minimize testing costs for modified code. However, you would think a "smart" tool could determine exactly what code needed to be retested. It would be great if such an automated tool existed to distinguish that kind of code in a "optimized" mode, i.e., determine the least amount of code that needed to be retested to demonstrate that a code conversion was correct."
Unfortunately, no such tool exists. This suggests that there is a serious need for tools that seamlessly integrate with Y2K conversion tools and that test Y2K conversions. If such tools existed, the total global cost of the Y2K problem could be reduced while still providing sufficient confidence that Y2K conversions were correct. This could add up to astronomical savings, as the world-wide cost for fixes alone is $600 billion, not to mention legal liability costs that could exceed $1 trillion [2, 3].
http://www.stsc.hill.af.mil/crosstalk/1998/01/y2kfixes.asp
