Could typing 07-26-9A as a date be made to work? Somehow? Or, as I suspect, would all systems have to be reprogrammed to accept it? Is the idea worth the time to investigate?

-- tom t. (tomusabomus@sisna.com), July 26, 1998

Answers

I think it's been established that the problem is not finding a solution, but more a problem of logistics, ie finding and fixing all the code and embedded chips in the time allotted. Many good solutions and tools have already been put forth, including the one you mention.

-- Amy Leone (aleone@amp.com), July 27, 1998.

HI Tom,

Good question. The use of hexadecimal numbers is one of the possible techniques which can be used if a company has a lot of archived data with fixed field lengths. By using hex, or binary coded decimal, or some other coding scheme (I've seen several variations on this) a company can fit additional date information into the existing 2 byte year field. You still have to write a lot of code to deal with the coding scheme you select and you may still have to convert old data, but you don't use any additional disk capacity and for large corporations that can save a great deal of money.

One of the biggest problems with date-encoding is handling data entry. You'll never get a clerk to consistantly type in dates like "9A".

Two other schemes are date-expansion (adding a 1 or 2 digit century code) and windowing (writing code which interprets numbers less than some value as being in the 21st century). Windowing also takes no additional disk space and has the added feature of requiring no conversion of existing data - but it won't work in every case. If the dates your program deals with go back too far, you can end up with a problem which is the reverse of Y2k - dates which should be interpreted as "1918" might be processed as "2018". Many of Microsoft's products use windowing. For some reason, Excel sets the window at 20 (i.e. 19 = 2019, 20 = 1920), and Visual Basic & Access both use 30. Don't worry though, I'm sure that people will stop using Excel by 2020, just like they stopped using Cobol in 1995.

-- Ed Perrault (EdPerrault@Compuserve.com), July 27, 1998.

The problem with all these so called fixes is, YOU HAVE NOT REALLY FIXED THE PROBLEM. Date expansion is the only real way to FIX the problem. Ya gotta go thru the code anyhow, fix it.

j

-- j (yada@yada.com), July 28, 1998.