>Hi John. My reasons for always displaying the century is that the user will for sure know if the date was interpreted by the computer correctly. If only 00/12/31 is displayed by the computer, the user can not be sure.
>
>>Why not? If you have SET CENTURY TO nCentury ROLLOVER nRolloverYear then an 8 character date field respects the right century. In fact, it's easier on the user to enter 01/01/01 for Jan 1, 2001 AS LONG AS the application can always determine the proper century.
>>
>>>I had allways used SET CENTURY ON myself, but I guess that someone would have set it OFF to cram more controls in a form, given the date control would take less space. Not a good solution, IMHO.
>>>
>>>>I am doing some y2k sniffing on a third party product and have come across several set century off commands? Why would someone use this command? I know their has to be a reason.

PMFJI: We have one other reason why CENTURY=OFF is used in our apps: Importing some poorly formatted data from an external host via SDF or CSV text files. Sometimes all I can get is a 2-digit year, and so we either do a 2-pass import where the 'date' gets sucked into a character field then converted to a different 'true' date field, or if the incoming field must be a date field to start with, we have had less problems with just setting century off, then checking it later for 'correctness' -- since the only app we have here at the bank with birthdates does use 4-digit years in the import file...

Rob