The claim that programs stored dates as two ASCII or similar characters because computers were limited in resources seems wrong to me because it takes more memory than one 8-bit integer would. Also in certain cases it's also slower.

Storing the year as one 8-bit signed integer would give (assuming 1900 + year) a range of 1772 (1900 - 128) to 2027 (1900 + 127). An unsigned 8-bit integer gives 1900 to 2155 (1900 + 255). In either case the end result is a much wider range and half the storage and RAM requirements.

In addition to perform arithmetic on the years the software would need to convert the two characters back to an integer whereas if it were stored as an integer it could be loaded without conversion. This is where the slower in certain cases comes in. In addition it could make sorting by year slower.

In my view the only reason I can think of for why someone would store a year as two characters is bad programming or using a text based storage format (such as something like XML or JSON which I know those are more contemporary in comparison to programs that had the Y2K bug). Arguably you can say that choosing a text-based storage format is an example of bad programming because it's not a good choice for a very resource limited computer.

How many programs stored years as two characters and why?

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Chenmunka
    Commented Jun 22, 2020 at 16:59
  • 1
    I believe it would have been either two EBCDIC characters or more likely two BCD digits.
    – dave
    Commented Dec 7, 2021 at 18:34
  • It occurs to me that I've never once, in a long programming career, ever stored a date as text (or BCD). Always it's a count of some time unit since some base date-time. (I did once use seconds-over-the-hill, where the base date was my 40th birthday - this gave a better range in 32 bits unsigned than the usual 1970-01-01)
    – dave
    Commented Dec 23, 2021 at 2:28

16 Answers 16


Short Answer: BCD rules over a single byte integer.

The claim that programs stored dates as two ASCII or similar characters because computers were limited in resources seems wrong to me

The point wasn't about using ASCII or 'similar', using only two decimal digits. That can be two characters (not necessary ASCII) or two BCD digits in a single byte.

because it takes more memory than one 8-bit integer would.

Two BCD digits fit quite nicely in 8 bits - in fact, that's the very reason a byte is made of 8 bit.

Also in certain cases it's also slower.

Not really. In fact, on quite some machines using a single byte integer will be considerable slower than using a word - or as well BCD.

In addition to perform arithmetic on the years the software would need to convert the two characters back to an integer whereas if it were stored as an integer it could be loaded without conversion.

That is only true and needed if the CPU in question can not handle BCD native.

This is where the slower in certain cases comes in. In addition it could make sorting by year slower.

Why? Sorting is done usually not by year, but as a full date - which in BCD is 3 Byte.

In my view the only reason I can think of for why someone would store a year as two characters is bad programming

Are you intend to say everyone during the first 40 years of IT, up to the year 2000 were idiots?

or using a text based storage format

Now you're coming close. Ever wondered why your terminal emulation defaults to 80 characters? Exactly, it's the size of a punch card. And punch cards don't store bytes or binary information but characters. One column one digit. Storage evolved from there.

And storage on mainframes was always a rare resource - or how much room do you think one can give to data when the job is to

  • handle 20k transactions per hour

on a machine with a

  • 0.9 MIPS CPU,
  • 1.5 megabyte of RAM, some
  • 2 GiB of disk storage?

That was all present to

  • serve 300-500 concurrent users

Yes, that is what a mainframe in 1980 was.

Load always outgrew increased capabilities. And believe me, shaving off a byte from every date to use only YYMMDD instead of YYYYMMDD was a considerable (25%) gain.

(such as something like XML or JSON which I know those are more contemporary in comparison to programs that had the Y2K bug).

Noone would have ever thought of such bloaty formats back then.

Arguably you can say that choosing a text-based storage format is an example of bad programming because it's not a good choice for a very resource limited computer.

Been there, done that, and it is. Storing a date in BCD results in overall higher performance.

  • optimal storage (3 byte per date)
  • No constant conversion from and to binary needed
  • Conversion to readable (mostly EBCDIC, not ASCII) is a single machine instruction.
  • Calculations can be done without converting and filling by using BCD instructions.

How many programs stored years as two characters and why?

A vast majority of mainframe programs did. Programs that are part of incredibly huge applications in worldwide networks. Chances are close to 100% that any financial transaction you do today still is done at some point by a /370ish mainframe. And these are as well the ones that not only come from punch card age and tight memory situations, but also handle BCD as native data types.

And another story from Grandpa's vault:

For one rather large mainframe application we solved the Y2K problem without extending records, but by extending the BCD range. So the next year after 99 (for 1999 became A0 (or 2000). This worked as the decade is the topmost digit. Of course, all I/O functions had to be adjusted, but that was a lesser job. Changing data storage formats would have been a gigantic task with endless chances of bugs. Also, any date conversion would have meant to stop the live system maybe for days (there were billions of records to convert) -- something not possible for a mission critical system that needs to run 24/7.

We also added a virtual conversation layer, but that did only kick in for a small number of data records for a short time during roll over.

In the end we still had to stop short before midnight MEZ and restart a minute later, as management decided that this would be a good measure to avoid roll over problems. Well, their decision. And as usual a completely useless one, as the system did run multiple time zones (almost around the world, Wladiwostock to French Guiana), so it passed multiple roll over points that night.

  • 30
    Another mini-anecdote: in the mid-'90s I was working on IBM mainframe systems, and added a new file to the system. IIRC, each record was something like 20-30 bytes, and included one date field; I took the hit and included the century. A couple of years later, colleagues were doing Y2K analysis, and asked me to estimate how much effort it would take to convert that file — they were amazed when I told them it was already Y2K-compliant! Even with only 5 years to go, most of my colleagues weren't planning for the end of the century…
    – gidds
    Commented Jun 20, 2020 at 17:34
  • 10
    "by extending the BCD range" Should we expect a 2060 "millennium" bug, then? :-D
    – Luca Citi
    Commented Jun 20, 2020 at 22:38
  • 13
    @LucaCiti Exactly 2059 would have been the last year were it worked. In fact, 2049 would have been the last, as X'F0' would have triggered another mechanism ... did I mention that space was premium when the system was conceived in the late 70s? THen again, it was finally retired in 2018, so it ended with X'B8', barely touching the X'Cx' range for some dates in the future (contract end dateor alike).
    – Raffzahn
    Commented Jun 20, 2020 at 22:47
  • 7
    I'd just add that BCD 2-digit year is still in use in some chips. Obviously now it implies year 20XX rather than 19XX. A recent example I've dealt with is BQ32002 RTC (but it also had a single century bit, to be fair), and I worked with a few more before, including a GPS module.
    – Alice
    Commented Jun 21, 2020 at 18:56
  • 3
    As someone who has had to write code to send data to these back-end financial systems, I can confirm that BCD, 80-character-wide fixed-width files, EBCDIC, and other such "outdated" formats are alive and well in 2020. I can't recall running into any which still only used two-digit years off the top of my head, but I wouldn't be surprised if they existed.
    – Bobson
    Commented Jun 22, 2020 at 14:07

I programmed in Cobol for nearly 20 years at the start of my career and it was quite common to see two digit years used. Initially this was due to storage concerns - not necessarily only memory, but disk storage also.

Cobol has no intrinsic date field.

It was very common to store dates in Cobol like:

     03 EMP-HIRE-DATE-YY    PIC 99.
     03 EMP-HIRE-DATE-MM  PIC 99.
     03 EMP-HIRE-DATE-DD   PIC 99.

If it’s 1970, you may not think your program is going to be used for another 30 years... it was more important to save those two bytes. Multiplied out by multiple fields and millions of rows, it all adds up when storage is a premium.

As 2000 started approaching, people had to start dealing with this. I worked for a company that had software that dealt with contracts and the end dates started stretching into 2000’s in the mid-80’s. As a rookie, I got to deal with fixing that.

There were two ways. First, if it was feasible, I added


To every date field. It ended up looking like:

          05 EMP-HIRE-DATE-CC.   PIC 99.
          05 EMP-HIRE-DATE-YY    PIC 99.
     03 EMP-HIRE-DATE-MM  PIC 99.
     03 EMP-HIRE-DATE-DD   PIC 99.

But in Cobol, you can’t just change that if it is a record description of a file... Cobol has fixed length records, so if you insert two bytes in the middle, you have to create a new file, read all the records in the old format, move them to the new record format, and write to the new file. Then “swap” the file back to its original name. If you are dealing with huge datasets you needed lots of disk space and time to do all that. And also rebuild all the programs.

When it wasn’t feasible, we added code when printing or displaying dates.


This bought another 50 years...

  • 4
    Exactly as it was.
    – Raffzahn
    Commented Jun 20, 2020 at 18:38
  • 4
    The system I'm working on now was designed in the late nineties, around the same everyone else was busy fixing Y2K. The original designers were downright fanatical about versioning every single record, no matter how trivial or how unlikely to change. Guess where that came from... Commented Jun 20, 2020 at 20:30
  • 10
    Maybe worth noting that COBOL uses a base-10 format. You chose how many decimal digits you want. That seems incredible, but it's an old language, well before 8-bit bytes. In PIC 99 the 9's are place-holders and PIC means picture. It means "the picture is 2 digits, no decimal point". There's no PIC 255 -- other options are PIC 999 and PIC 9999. Commented Jun 20, 2020 at 20:47
  • 6
    USAGE BINARY aka USAGE COMP aka USAGE COMPUTATIONAL could be used to take less storage but in my experience were generally not used in file record descriptions, mostly Working Storage variables. The storage of COMP varies by implementation I believe, based on word size, endianness, etc.
    – mannaggia
    Commented Jun 21, 2020 at 2:45
  • 2
    @mannaggia Frugal? Coding sheets! Coding sheets so the code could be sanity-checked before we wasted disk space and processor cycles! I'll stop there - I'm aware I'm in danger of becoming one of the Four Yorkshiremen...
    – Spratty
    Commented Jun 23, 2020 at 14:16

To add to Raffzahn's answer, here's an example from a 1958 book on data processing:

Standard IBM punched card with literature reference coded

… The names of authors are coded in columns 11-14. The first four consonants of the name form the code. The last two digits of the year of the reference are punched directly into columns 15-16. The journal, or other source for the reference, is coded in columns 17-20. …

(from Punched Cards Their Applications To Science And Industry. 2nd ed. Edited by Robert S. Casey, James W. Perry, Madeline M. Berry and Allen Kent. New York, Reinhold Publishing Corp; 1958; emphasis mine. The card image shows 52, assumed to mean 1952, in the noted columns)

This book barely touches on computer applications, since unit record usage was more prevalent at the time. Computers inherited these tabular data formats, and the physical inertia of the data format — cardboard boxes containing millions of records — meant that tabular years stuck around for a very long time. The book does have a couple of mentions of dealing with centuries, but the typical outlook can be summarized by the quotation from p.326The century is neglected inasmuch as most entries for this particular file are in the 20th century”. Would you spend/waste 2½% of your available fields in a record just to encode something you (probably) won't use?

Data, especially government data, sticks around for a long time. Consider this: the last person to receive a US Civil War pension died in May 2020. The US Civil War ended in 1865. Tabulating equipment didn't come in until the 1880s. Bytes didn't happen until 1956. JSON was this century. So data formats tend to be what the past gives you.

  • 1
    Good perspective about longlivety of data formats.
    – Raffzahn
    Commented Jun 20, 2020 at 18:15

There are actually still RTC chips on the market which store the year only as a pair of BCD digits, and do not have a century field. These are usually packed into one byte when read, in common with the fields for day-of-month, month-of-year, hour, minute, and second. The same format is used for the alarm settings.

Old software using these chips would simply prefix the year digits with 19 for display. Current systems using them would prefix 20. The problem rears its ugly head whenever the system is used in a century that it wasn't designed for - so potentially also in the year 2100.

If an RTC chip existed that counted in binary instead of BCD, then it could handle years in two and a half centuries without trouble. An old machine adding 1900 to the stored year would not see any rollover trouble until after the year 2155. This would however require the host system to convert binary to decimal for display - not a problem for a PC, a minicomputer, or even an 8-bit microcomputer, but potentially a burden for extremely lightweight embedded systems.

  • 2
    There is a rollover issue with RTC. The Atari 520 ST and 1040 ST use a 6301 RTC chip. The chip will rollover from year "00" to year "01" assuming year "00" is a leap year. This works for 2000, but not for 1900 or 2100. The Atari ST BIOS just adds or subtracts 80 from the year when converting from/to the RTC format to a 16 bit integer format, where the year field is year minus 1980 (same as PC-DOS). I wrote a program to support years 1980 to 2079 with the RTC.
    – rcgldr
    Commented Jun 20, 2020 at 19:38
  • 3
    @scruss: Even the RTC hardware built into some 32-bit ARM chips such as the STM 32L series uses BCD for everything. What irks me most about such things is that there are very few applications where having a hardware clock in YYMMDD format would offer any advantage whatsoever compared with having a linear counter, despite the fact that the hardware is almost certainly more expensive.
    – supercat
    Commented Jun 20, 2020 at 22:08
  • 2
    @supercat The hardware (but really software - firmware or microcode?) is marginally more expensive, but it means that retrieval is much simpler, as you don't have to decode a number of days (what's the start date? leap years?) into YYMMDD, which is what you typically want. Unless you want Unix time...then the Y2038 problem. Commented Jun 21, 2020 at 4:58
  • 2
    @supercat If you presuppose that your computer has a sophisticated date/time processing library, then it probably does make sense to implement a straight binary counter and let the host CPU turn it into something human readable. However, most devices containing RTC hardware have extremely limited processing capability. The discrete RTC chips are most likely direct derivatives of the hardware that also goes into watches, clock radios, and suchlike. Having the RTC work in human-readable format directly is then more convenient.
    – Chromatix
    Commented Jun 21, 2020 at 17:56
  • 2
    @Chromatix: Incidentally, a similar issue arises with zero-terminated strings. There are some use cases where they offer some advantages over alternative formats, but unless strings are of trivial length, or the only thing one will do with a string is process the characters thereof sequentially, tracking the length as a number will be better than trying to use the location of the first zero.
    – supercat
    Commented Jun 21, 2020 at 22:24

Another point that hasn't yet been mentioned is that many programs would store data in whatever format it was keyed in. If data was stored as six digits YYMMDD, that's what data-entry clerks would be expected to type. For a program to store data as YYYYMMDD, it would be necessary to either have clerks enter an extra two digits per record, or have software compute an extra two digits based upon the two digits of the year the person typed. Keeping information as typed, but using modular arithmetic so that 01-99=02 wouldn't necessarily be any more difficult than having to add extra logic at the data entry stage.

  • 2
    Space on punch cards was limited to 80 characters. Short cuts like a two digit year number could be important for keeping a complete record on one card. Commented Jun 22, 2020 at 7:48

Additional examples:

  • In banking, many computations have historically used binary-coded decimal (BCD) as a compromise between space, speed, and consistent rounding rules. Floating point was uncommon, slow, and difficult to round off consistently. So even things like interest rates might be stored in fixed-point BCD. Something like an interest rate might be stored as four BCD digits, in two byes, with an implicit decimal point after the first digit. Thus, your account could pay interest rates from 0.000% to 9.999%, which seemed perfectly sufficient, because a bank would never pay 10% or more. This thinking left 1970s programmers scrambling to update data structures when high inflation and new types of accounts like Certificates of Deposit crossed that threshold.

  • When gas prices first cross the $1/gallon threshold, many of the pumps could not be set with the actual value. Though that was largely a mechanical limitation rather than what we would consider a computing problem today, the thinking that led to the situation was largely the same: reduce costs by not bothering to enable values that were unimaginably large at design time.

  • [Apocryphal] When the first 9-1-1 emergency dispatch service was put into use in Manhattan, legend says its database schema hadn't anticipated five-digit apartment numbers, leading to delays of paramedics reaching sick or injured high-rise dwellers.

  • In the 1990s, phone numbers in North America Number Plan were all of the form (AAA) BBB-CCCC, and the second A was always a 0 or 1, and the first B could not be a 1. (There were other restrictions, too, but they aren't relevant here.) By exploiting the well-known restrictions, the contact management software on your PC could represent a phone number with a 32-bit value, saving disc space and RAM (at the run time cost of a little bit swizzling to encode and decode the values). But the soaring popularity of fax machines, pagers, modems, and cell phones drove demand for phone numbers until North America ran out of area codes, causing software publishers to scramble to update their software to use less elegant space-saving tricks.

  • It's not always about memory savings or binary-coded decimal. Sometimes it's about space on a form or a display. In high-end software for stock trading, display space is at a premium. When it first seemed the DOW Jones Industrials Average could potentially break $10,000.00, there was concern about whether these displays would show the additional digit, and whether there was room for a thousands separator. If the values were truncated or displayed in other confusing ways, would it slow down the traders who relied on these system? Could it trigger a DOW10K panic sell off if it confused them into thinking the value had plummeted?

  • The phone number part is quite interesting - and complete new to me. Do you remember any software doing so?
    – Raffzahn
    Commented Jun 21, 2020 at 19:33
  • @Raffzahn: QuickBooks for DOS. But I'm sure there were others as well. Commented Jun 21, 2020 at 21:09
  • 1
    The North American phone number rules were well known (in North America...) and commonly used either for compression (as noted) or as a classic example of data validation/input field formatting. Commented Jun 21, 2020 at 23:51
  • 1
    Another example from banking: I knew someone who had to work with an electronic funds transfer program that limited transactions to 999 999 999.99 of the monetary unit involved. A reasonable limit, because there just aren't very many billionaires, right? Well, not in USD, EUR, or GBP. But someone had to wire a large amount of money to Turkey, before its 2005 currency reform, when the exchange rate was around a million Turkish lira to a dollar.
    – dan04
    Commented Jun 26, 2020 at 0:14

Microsoft Word did

I distinctly remember looking into the binary .doc format used by Microsoft Word 5.0 for DOS, because documents saved when the year was after 1999 couldn't be opened again. It turned out that the internal meta-data included the date using two ASCII digits for the year and 2000 was blindly stored as 100, thus overwriting one byte of an adjacent meta-data field, breaking the document.


The mainframes have been covered. Let's look at what led up to the PC which of course is where a lot of business software evolved.

Many PC programmers had previously been programmers for 8-bit systems, and had grown up on the "every cycle counts" mentality. Many programs for MS-DOS had ports for older 8-bit systems, too, so would have often followed the same internal formats.

  • Most 8-bit CPUs (and also the 16-bit CPU used in IBM PCs) had specific BCD instructions, which operated on one pair of decimal digits.
  • Most 8-bit CPUs did not have multipy or divide (or mod) instructions at all! To convert from binary to base 10 and back was a lot of work and involved loops or tables. OK, you could use two BCD bytes for a 4-digit number, but if you wanted to, e.g. subtract one date from another it would have required maybe five times as many assembly instructions/cycles.
  • In terms of RAM, having each date take an extra byte or two is one thing—having 5-10 extra instructions to deal with it was not worth it when you have 64KB of RAM or less. Consider that even by just typing the number "86" the program would have to add 1900 to it.
  • Assembly language instructions don't just take up space—assembly language programming is hard! Every instruction took up a line of screen space, had potential for a bug, and consumed a bit of the programmer's headspace. (Everyone was confident at working with BCD; it has now fallen by the wayside because of high-level languages.)

While we're on the topic of screen space, many programs didn't even display a leading "19" on the screen. (Hello—40 character screen width!) So there was hardly any point at all for the program to keep track of that internally.


Back in olden times (1960s and earlier), when data came on Hollerith cards (80 columns, 12 rows), using 2 extra columns (of the 80 available) to store the fixed string "19" as part of a date seemed useless.

Having more than 80 columns of data meant that one had to use multiple cards, and lost several columns to the overhead needed to say "I'm with him", plus the extra programming effort to validate the pairing.

Hardly anybody thought their code would still be in use when "19" changed to "20".

Anybody who stores fixed field size dates as "yyyymmdd" has a Y10K problem pending.

  • 12
    It really needs to be emphasized that to everyone born prior to ~1995, 2000 wasn't just "the year after 1999", it was literally "THE YEAR TWO THOUSAND"... a futuristic utopia where we had colonies on other planets, flying cars, android servants, and a Star Trek economy. By the 1990s, it was obvious none of them were happening anytime soon, which made Y2K seem even FURTHER in the future. The fact that we had no agreed-upon demonym for "the first decade of the 21st century" made it even harder to talk about... The Fifties? Sixties? Seventies? Eighties? Nineties? Then... um... EVENT HORIZON!
    – Bitbang3r
    Commented Jun 21, 2020 at 16:23
  • I still want my flying car from Back to the Future 2, the Future day was October 21, 2015. Commented Jun 22, 2020 at 9:25
  • 2
    Quite often the comment returned by the coder would be that will be in 20/30 years' time - I don't expect that they will still be using this program
    – cup
    Commented Jun 24, 2020 at 5:25
  • 4
    @Bitbang3r: I (born in 1982) can attest to that. During my childhood, almost every prediction about the future, whether optimistic (flying cars, men on Mars, cure for cancer) or pessimistic (destruction of the rainforests, World War 3) was “by the year 2000”. It was The Great Deadline for everything. Then 2000 actually came, and went, and life went on as usual.
    – dan04
    Commented Jun 25, 2020 at 23:47

I worked with IBM minicomputers (S/36, S/38, and AS/400) in the 1980s and 1990s. The very ugly programming language RPG was popular. It looked very different from Cobol but had similar abilities. It supported only two data types: fixed length alphanumeric and fixed precision decimal numeric. The numeric variables could be zoned which meant one digit per byte or packed which was two digits per byte. Storage of dates varied quite a lot but the most common was as 6 digit numbers rather than separate year, month, and day. Usually, but not always, these would be YYMMDD in the database so that the sorting would be sensible.

Numeric fields were always signed so the last half of the last byte was reserved for the sign (hex F for + and hex D for -). So, a 6 digit number required 4 bytes rather than 3 and the first half of the first byte was unused. This allowed a trick when year 2000 became an issue: the unused first half of the first byte could be used for a century flag: 0 for 19xx and 1 for 20xx. The format is usually described as CYYMMDD. Systems which use this format will have a 2100 or 2900 problem but the culprits won't be around to see it. Actually, many systems will have a problem sooner as 6 digit format is still popular for display and entry. Arbitrary cut off dates, e.g. 40, are used to guess the century when 6 digits are entered. So, 010195 is assumed to be 1995 but 010115 is assumed to be 2015. So, a problem is due in next couple of decades for some but it won't be as bad as the year 2000 since at least the database can cope beyond the limit.

On BCD and performance, BCD is not necessarily much or any slower since machines intended for business use usually have hardware support. Also, conversion to and from human readable format is simpler. Many business programs will display and accept entry of data far more often than perform arithmetic on it so even if there was an arithmetic performance impact it would typically be outweighed by the I/O gains.

Not relevant to dates but BCD is useful for money. Try adding 0.01 up 100 times in a float or double and then comparing it to 1.00. BCD gets this right but float and double don't. Accountants get very upset if the balance sheet is off even by a cent.

  • All of my programming experience had been Perl with PostgreSQL on Linux then VB Script/C# on Windows with SQL Server and Oracle. About a year ago I started reading data from DB2 on an iSeries and wondered where CYYMMDD came from. This is enormously helpful! Commented Jun 22, 2020 at 14:31
  • So, you have always had a date data type in the database. This date nonsense is from an era when there was no such thing. Not only did we worry about a few bytes but we also lacked many tools and concepts. Most people did not even feel the lack of a date data type. Dates looked like numbers so they were numbers. DB2 on iSeries now has a date data type but a lot of the software comes from the earlier era.
    – badjohn
    Commented Jun 22, 2020 at 14:36

The NORAD Two Line Element format remains in wide use for cataloging satellite orbits. Originally intended for punched cards, it uses a two character year. Years <57 are defined to be in the 21st century. It may be supplanted soon, though. The immediate problem is not years, but the number of trackable objects in orbit.


You may not remember the enormous market share that IBM occupied in the business computing space in the 20th century. I don't mean just the mainframe market where S/360, S/370, S/390 & their successors play, but also the much larger (in terms of units) midrange/small business market occupied by the S/3, S/32, S/34, S/36, S/38, AS/400, and their successors. IBM's midrange systems were ubiquitous in smaller businesses and in branch offices of mega-corporations around the world, and at their peak they brought in $14 billion annually to IBM.

To be successful in this target market, these systems had to be far more affordable than a mainframe. And since "inexpensive" disk storage cost around $10,000 per GB in 1990, disk capacities were small by modern standards. You might only have 13 MB -- yes, MEGABYTES -- of total disk capacity to work with online on a S/32. That's to serve a corporate operation with reveneues of $250 million and up (that's IBM's definition of "small business") and running accounting, billing, payroll, inventory control, manufacturing production control, and similar applications, which are all about DOLLARS and DATES.

And these were all EBCDIC machines.

So yeah, absolutely, EVERYONE used 2-digit years on these systems prior to Y2K.

Fortunately, disks got cheaper in the late 1990s, and thousands of contract programmers put out Y2K consulting shingles at about the same time. In the 3 years from 1997 to 1999, most of the mess got cleaned up. I'm sure that here and there, a dental office had billing with dates in the wrong century, or a mortgage amortization schedule showed negative dollars owed after the turn of the millenium, but the truly bad-news applications that could hurt customers on a massive scale got fixed before zero hour on December 31, 1999, 23:59:59 UTC.

  • 2
    And Bitbang3r is absolutely correct about THE YEAR TWO THOUSAND being THE FUTURE. It didn't feel like a real year that might actually arrive in our lifetimes until 1996 or 1997.
    – telms
    Commented Jun 22, 2020 at 8:35

Even systems that stored the year as a byte often just printed "19" in front of the value. So the year 2000 (stored as 100) would be printed as 19100 or 1910 or 1900 depending on exactly how the number was converted from a byte to printable characters.

Of course a lot of systems didn't even both printing the 19, they just printed 100/01/01 or 00/01/01. Similarly date entry systems often only accepted two digits making it impossible to enter years beyond 1999.


Many fixed record text formats (with or without COBOL copybook definitions) used two digit years, and some do still in this year. So it does not only affect storage format (like in databases) but also interchange formats. Those formats deliberately did not use binary representations but did try to be compact.

This happened way into the 90ies, where everybody knew about the upcoming millennial change.

Funny side note, many systems used the year 2020 as cutoff, which results in a increased problem rate this year, again.

Even in standardized EDI Formats like X.12 or EDIFACT you see the 4 digits years optional. The Date or Time Period Format Code 2379 for example starts with code "2" being DDMMYY. (And back then I was a really bad idea to allow more then one unique format for each instant type). One of the major drivers for switching EDIFACT syntax version from 3 to 4 in 1998 was the 8 digit date stamps in UNB service segment.

Another example would be the VDA fixed record messages used in the (German) automotive sector, things like VDA 4912 from 1991 specify delivery date in 6 digits (or even shorter with week numbers). They have been in used way past 2000.

  • Another issue with 2019 or 2020 is that some programs may expect people to type dates without pressing enter (or, for phone-response systems, the pound key) afterword; for years prior to 2019, one could assume that if the first two digits typed were "19" or "20", they were the hundreds part of 20th-century or 21st-century years. Once there was no need to accommodate twentieth-century years, one could drop the special treatment of "19".
    – supercat
    Commented Jun 23, 2020 at 21:40

Y2K issue was principially caused by the need to save disk space/storage in relation to dates - as mentioned already storing a date of DD/MM/YY requires less space that that of a date of DD/MM/YYYY - i.e. you would be saving a two bytes for every date on every record - as mentioned when disc space was limited/expensive this was the norm.

Prior to Y2K activity (late 90s) I had to work on a 1980 date issue, because our systems that were in use would remove the decade part of the year and then pack the date i.e. the date was stored as DDMMY. When this was saved as packed decimal this would then only require three bytes of storage. When ever dates needed to be printed then date was reformatted and a constant of a 7 added for the decade (i.e. date saved as S31057 - printed as 310577).

Mid 1979 we started getting statement due dates appearing with a year of 1970 instead of 1980 due to the above, which needed remediating on the same basis as some Y2K fixes i.e. checking single part of the year date to be greater than five force a 7 if less than or equal to 5 force a 8. This ensures a couple of years extra use. Glad to say I left company before 1985 so don't know what materialised then.

Since that time I have met older developers who say they has same issue with dated oving from the 1960s to 1970s, although I guess not as many.


To add another data point, there are systems in development today that do not use 4 digit years.

One such system uses a 7 bit number to store the year, with the assumption that 0 is the year 2000. This is done to save space during transmission. This will theoretically work till the year 2127, but I really don't know what will happen at year 2100.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .