>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
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only