Today we got a Y2K pamphlet in our bank statement. Of course everything is jim dandy, but they said they tested dates that could cause problems and mentioned one I hadnt heard about before. What problems might 01-10-2000 cause?

-- CuriousGeorge (spider@web.com), September 30, 1998

Answers

The potential problem with 10-10-2000 has to do with a count of the digits. Depending on the techniques used in remediation, 01-10-2000 man have similar problems, since 10 is the first month requiring two digits for the month field. The issue is whether enough space was allocated in the date field of the record(s) to contain this extra digit.

-- Flint (flintc@mindspring.com), September 30, 1998.

You're talking about October 1, 2000 - right?

-- Mike (gartner@execpc.com), September 30, 1998.

October 1st, 2000!

The date I'm worried about right now is October 1st, 1998.

My dang rent is due.

-- Craig (craig@ccinet.ab.ca), September 30, 1998.

There is another set of dates including 9/9/99 to consider; programmers sometimes used that combination or something similar to indicate a record that should be deleted or a sort order, apparently. That can't be checked for without reading the code, however, or using a test tool that will check for this particular case, so it's a bit scarier than Y2K in that it's mentioned only infrequently and much harder to track down (and consequently, harder to fix as it's harder to find).

-- Karen Cook (browsercat@hotmail.com), October 01, 1998.

In answer to Karen, it is unlikely that 9/9/99 will cause a problem. The value held in the date field would be 090999 (MMDDYY). Yes 9s do have a special significance in programs, usually to indicate End of File condition (last record sorted to end) when programs have to execute close down routines after processing a file. Alternative they may signify special records, eg ones containing parameter data or accumulated totals. However the 999s value (used as it would not normally be contained in data) would have to be detected in the key field as ALL 9s, ie to trigger off EOF routines from a date the program would have to be using a date field as a primary key (unlikely as dates are not unique) and the fields would have to contain the value 999999. Clearly the value 090999 would not trigger off these events. Date fields are normally searched in a browse mode when the date would be the key, an update program is unlikely to process files by dates. It would normally use a unique key such as Account Number. There will still be problems in 00, when programs attempt to subtract 99 from 00, but we all know about that.

-- Richard Dale (rdale@figroup.co.uk), October 01, 1998.

What time is it when the bank strikes 01-10-2000?

Time to change your bank - they can't proofread their own advertisements.

This date means nothing in anything I've read. The European date convention reverses month and day in number format - so this could be (what we would read) as 10-01-2000 in European format, which is the start of the federal 2000 fiscal year, but that's stretching things a bit.

Course, then again, maybe they are planning on shutting down from 01-01-2000 til 01-10-2000.

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), October 01, 1998.

1/10/2000 could be the first time that particular bank performs some periodic transaction (like statement generation) after the rollover.

-- Paul Neuhardt (neuhardt@ultranet.com), October 01, 1998.

Richard, I wish I had enough information about the nines problem. Perhaps you know more.

I followed a long discussion about this over a year ago. From (hazy) memory, I learned:

1) The actual storage format isn't the point, what's important is the way the code that processes the files interprets it. Whether or not it is possible to enter a logical switch into the data from the data entry screen is the key. 12/31/99 is more common as a switch than 9/9/99. If the processing code decides that 090999 means something special and isn't a date, the same problem can occur.

2) Using dates as logical switches has been more the result of user cleverness than programmers' intent. Users notice how sorting or reporting works, and create date field values to force these sorts or reports to come out the way they want them. In a real case reported by DeJager, the users were using a year of 00 to indicate an unpaid invoice, so that these would appear at the top of the report. When the y2k fix went in, this didn't work anymore, so they started entering a year of 9999 and sorting inversely. The system promptly crashed because somewhere the program was calculating elapsed days, and there were so many days in 9999 years that a memory location was overwritten when storing this unexpectedly large number.

3) The incidence of dates used as logic switches is unknown. A couple of these in critical places can as always do more damage than a thousand of them in cosmetic locations.

4) This problem can be hard to find during remediation, because it belongs to a class of problems other than what you're looking for. It isn't really a y2k bug at all, simply a date value that 'won't come for a long time, so I don't have to worry about it.'

-- Flint (flintc@mindspring.com), October 01, 1998.

Flint, I've come across the 31/12/99 problem being used extensively as an End Date which originally was way in the future. It was used at an installation I worked at on a general purpose database holding 'bucket' data that could not find another home. Every record was accessed by a multiple key including start and end dates, there may be several records for a search with data in force over various date spans. That one problem in itself had it been left uncorrected would have brought every system down for weeks. I have seen only all 9s used as a special non-data value that could be confused with real data. Use of high values (hex FF) and low values (hex 00) is also prevalent on header and trailer records however they could definitely not be user-entered. I'm not saying that systems may not use 00 or 99 in the YY date field to mean something other than a year, but it may be less common. When it comes down to it a program can be written in any way the author decided at the time. Because date processing happens to be an area that was not really subject to proper programming standards, you have to look at every line of code, or at least at representative samples.

-- Richard Dale (rdale@figroup.co.uk), October 02, 1998.