Reply to post:

Some of us mainframers, at least those of us progamming ICL kit in the 1960s, 70s and 80s, were used to storing dates as days since 31Dec1889 in 24 bit words, which works well, leapyears and all, into the 22th century.

We still had problems with Y2K but that was due to the CODASYL gang, which decreed that the ONLY way a COBOL program could access the computers clock to get the date was with the statement

ACCEPT CURRENT-DATE FROM SYSTEM-DATE.

where CURRENT-DATE was required to have 6 digits that would be filled by a date in the format YYMMDD and SYSTEM-DATE was a system-defined name which was specific to the operating system and/or compiler. Unsurprisingly, as the century was not part of this CODASYL definition until sometime in the 1990s, almost all COBOL programs did the same and consequently they hard coded the century wherever it was required to be shown. Most programs written in assemblers and, I think, PL/1 together with a lot of 4GL systems shared this limitation and these were the systems that caused the Y2K panic.

The only COBOL system I was personally associated with that was written in the early 1980s and dodged that bullet had to deal with a wide range of date formats, some inexact, i.e. 'flourished 980AD' (i.e. they were alive then but we don't know when they were born or died). The required date range extended from the pre-Christian era, into the future to handle planned events. Precision varied equally widely, i.e. Euripides was alive in 55BC, birth and death dates unknown, Turold wrote the Song of Roland some time in the 11th century, while John Cage was born 5Sep1912 and died 12Aug1992, but we needed to invent our own date representations to make this work. So, we stored dates as Xccyymmdd where X was a code representing the format required for this type of date and controlled both input and display as well as validation rules. Precision was simple - we just set the day, month and year to spaces if they weren't known and the date display code formatted it appropriately.