The assumption is that date format has been set to ymd, leading zero day, leading zero month, Century year in "International".
Unfortunately a small problem with filemanager displays has been observed.
Using the test file directory generated in Topic 002,the following results were obtained.
File name Filemanager display 20000229.dat 19:0/02/29 20010301.dat 19:1/03/01 20020902.dat 19:2/04/02 20030503.dat 19:3/05/03 20490604.dat 19>9/06/04After some panic and investigation the following evolved:
Decade Win 3.1 Coded
21st Century
Decade
200x 19:x/mm/dd 201x 19;x/mm/dd 202x 19Where x = 0 thru 9, and is of course the year.x/mm/dd 205x 19?x/mm/dd 206x 19@x/mm/dd 207x 19ax/mm/dd 208x 19bx/mm/dd 209x 19cx/mm/dd
This is absolutely symmetrical and regular, therefore Humans, given the little table above can correctly interpret the displayed date.
Peculiar, but true.
Think of it as a weird Hex code specially invented to make your life less dull.
(This should specially please all the weirdos that want to put Hex dates into the mainstream.)
This is not a bug, it is a feature.
Acceptability Index 8, Borderline. Result Acceptable, Poor but acceptable, as it can be interpreted by humans(with difficulty) is display only and does not cause system damage or file corruption. We shall see.
The test files have been expanded to include every decade within the 21st century to see exactly where programs and displays will potentially croak.
The Windows "Clock" program when set to digital mode displays 2000/02/29 quite happily. Acceptability Index 0.
This also implies that the garbled "21st Century decade code" problem is localised to Filemanager. Now there is an opportunity for some bright and eager bit-twiddler.
Vern Buergs LIST 9.1k is quite happy running in a PIF environment under Windows 3.1 and achieves the same results as under DOS. Acceptability Index 2.