Re: Question: How will the Year 2000 bug impact your work?
Posted in 1996
Topics: Stored Procedures & SPL
In article <3274EB3D.7CAB@uci.edu>, Hank Liao <hhliao@uci.edu> wrote: > >What you said are all correct. 2-digit year display can be changed to >4-digit year display by simply set century on, however, the problem is >the screen real estate. <snip> > >Without any modification, these 2-digit year would have problems with >the year 2000 issue. We are currently adding a function call in the >VALID of all date fields to call a convertion function to assign 2000 to >years between 00 and 49, and 1900 to years between 50 and 99. We will >need to modify the programs again around years 2045, but we will only >need to modify the procedure to change the assignment values, and >hopefully the programs are smarter by that time. > >Hank Liao Why not write a function that will NEVER need to be changed. It is surprisingly simple, and here's how... Get the current 4-digit year, and subtract 90 from it, then extract two values: the century, CC, and the last two digits, YY. (In 1997, CC will be "19" and YY will be "07".) Now, compare the 2-digit year entered by the user on a screen to YY. If the user's entry is greater than YY then use CC as the century. If the user's entry is less than or equal to YY, add 1 to CC to get the century. Using this method in 1997 returns 19 for the century for years 08 through 99, and 20 for the century for years 00 through 07. Each year, the algorithm advances one year. This "sliding century algorithm" will ALWAYS work because it starts with the current year as its base of calculations. You never have to re-code anything, no matter what year you are in. It forces a date to contain a century within the range of 89 years BEFORE, and 10 years AFTER the current year. By changing the 90 in the beginning of the algorithm, you can modify the range of years assigned to each century. Hope this is useful. I can send the actual code written in Oracle's PL/SQL, if you want. Steve Cosner