Testing Microsoft Windows 3.1

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/04

After some panic and investigation the following evolved:
Lesser known facts about Windows 3.1 Filemanager.

Decade Win 3.1 Coded
21st Century
Decade

200x    19:x/mm/dd
201x    19;x/mm/dd
202x    19x/mm/dd
205x    19?x/mm/dd
206x    19@x/mm/dd
207x    19ax/mm/dd
208x    19bx/mm/dd
209x    19cx/mm/dd

Where x = 0 thru 9, and is of course the year.

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.