There’s a difference between display issues (your screen currently says 8/13/99 and on New Year’s Day will say 1/1/00) and info storage issues.
If you have a spreadsheet column or database field that is set to calculate a date, and your display is set to 2-digit date display, a Y2K compliant system will still be able to subtract today’s date from New Year’s Day and show 140 days, even though the display says 1/1/00 for the January date. A non-Y2K compliant system will treat 1/1/00 as 1/1/1900 or as an error; and, worse, if you add 140 days to today’s 8/13/99, it may lack the capability to store the information as Jan 1, 2000.
If you want to test your system and software for Y2K compliance, open up calendar programs, calculation-capable programs such as spreadsheets and databases, appointment minders, and word processors that let you enter a date code rather than a hand-typed string; See if you can enter 21st century dates, can subtract 20th century dates from 21st century dates, can add #days to 20th century dates that yield a 21st century result, display an appointment calendar for 21st Century months, etc. THEN change your date and time control panel to make “today” = a 21st century date; auto-enter “todays’ date” where applicable; ask for today’s calendar and see if you get the right one; etc.
Some of the worst offenders are export and import from other file formats. Try exporting spreadsheet data to plain text and reimporting it, with date fields storing 21st Century dates and see if they come back in garbled or not. (In all fairness to the programmers, I think it is reasonable to make 20th century assumptions about 2-digit year dates imported from text files, since you have to make SOME kind of assumption there and, presumably, by the time people were/are entering 21st century dates, they ought to be / should have been using 4-digit year dates for plain text!)
Designated Optional Signature at Bottom of Post