Older ATM Machines. They may think that your ATM or credit card that expires in 2002 is already expired. Note that this problem will come up as soon as you have a past-1999 expiration date on the ATM card.
Further, it is likely that there will be a "run" on ATM funds near the end of the year due to general paranoia. It might be wise to have a bit of extra cash on hand before the end of the year simply because other people will do stupid things.
Credit card validation systems. See ATM Machines. This should be less of a problem to fix, because these systems tend to be cheaper (e.g. more readily replaced) than ATM machines.
Many PC's BIOSes will wrap around to other dates on 2000/01/01.
Airline reservation information might have a brief "hiccup" for the few days before and after However, as scheduling systems manage really huge amounts of data, operational data tends to be purged within a year, so that systems tend to assume that only some portion of last year, this year, and next year exist. In other words, if the system can handle moving from one year to the next, it shouldn't have any particular problem with Year 2000.
More serious problems may be had by mainframe-based air traffic control systems. It is not yet clear what Y2K problems they will encounter.
Be careful about using elevators and other pieces of equipment that may have automagically-scheduled maintenance. Maintenance schedules may get miscalculated; no inspection needed for 79 years. Or the elevator may shut down because it thinks it's never been inspected before, and needs it immediately.
If your enterprise receives EDI information from other enterprises, any problems they have can pass on to you. The EDI standards contain significant Y2K ambiguities despite the fact that they're new enough that they shouldn't...
Banks have been aware of the "Y2K" problem for several years now (and usually have products that get hit long before 2000), so that major problems at your bank are not too likely. But access to funds in your bank account that pass thru other sorts of institutions is liable to be "iffy."
Most of these problems are truly inexcusable as it is easy to avoid the problems with just a little bit of forethought. The problems seen on recent PC-based sytems display an utter lack of foresight (and arguably of competence) on the part of the people that managed the creation of these computer systems. In the interests of saving a few thousand dollars worth of disk space for a few years, nightmares that will cost literally billions of dollars to fix have been created.
Mainframe-based problems will be as difficult to resolve, but the arguments do not show designer incompetence quite as readily:
Some mainframe systems have been operating for decades; they were designed before there was reasonable expectation of Y2K being an issue.
Many data structures were designed to transfer data based on fixed-width punchcards either 72 or 80 characters wide. Since columns were a strictly limited resource consuming two characters for century/millennium information appeared excessive.
Other problematic dates:
01/01/99: Reservation systems booking a year in advance.
04/01/99: NY State fiscal year begins
07/01/99: 44 other states fiscal year
09/09/99: possible EOF indicator of 9999 problem
It is commonly claimed that September 9 is a date when care must be taken because some systems used the value "9999" as an "end-of-epoch" indicator.
I have a very difficult time believing that this is likely to cause any real problem, because September 9 would be represented as "990909" or "99909," neither of which actually matches with "9999."
My suspicion is that somebody looked at the date, saw that it had "a whole bunch of 9's," and essentially made the numerological statement that September 9 could cause problems.
10/01/99: Fed fiscal year
I'll likely be collecting up a minor stock of "stuff" so as to avoid problems; it does little damage to have a bit of extra bottled water, canned goods, and other such stuff so as to avoid doing too much shopping during days when the more gullible are likely to be panicking.