Only last two digits of a year, until recently,
were stored.
1950 is stored as 50
1999 is stored as 99
2000 is stored as 00
2001 is stored as 01
Whereas 1999 is before (less than) 2000,
99 is after (greater than) 00
any logic dependent on date sequencing has the potential to err
Your mortagage payment is due 1/1/2000.
You send it in on 12/15/1999
Payment must be received before due date;
i.e., receipt date < due date
and indeed 1999 < 2000
If 2000 is stored as 00 and 1999 is stored as 99,
then 99 > 00 and payment likely not to be credit.
This problem is pervasive in banking, transport, telecommunications,
retail, etc. -- any system that processes date sequences.
Many old programs exist with this problem in the range of billions of lines of code.
How are these programs repaired?
See
IBM's site
for example
Expansion
In each program, expand year to CYY or YYYY,
where C is a century indicator
(0 = 19; 1 = 20; 2 = 21)
Requires program and database and layout changes
Windowing
Establish a 100 window.
Century of a two digit year is determined by where it lies in window
Assume all dates fall in 1 Jan 1954 to 31 Dec 2053.
If YY > 53, assume 19YY
If YY < 54, assume 20YY
Requires only program changes
Encoding
Encode 4 digit year into 2 digits
Hexadecimal (1900s and 2000s have same century digit (07)), or
unsigned packed decimal