>>>Why would a command such as:
>>>? ctod("10/13/15")
>>>give me the following result?
>>>10/13/2115
>>>In other words, next century instead of the current century.
>>>
>>>I am trying to import data from a text file, and thought ctod() would be a quick solution. Actually the dates seem to include a century, so the question might be irrelevant for this particular task, but I was still curious what I did wrong.
>>>
>>>Here are some relevant settings (Visual FoxPro 9):
>>>set("date") = "AMERICAN"
>>>set("century") = "ON"
>>>set("century", 1) = 20
>>>set("century", 2) = 65
>>>set("century", 3) = 2029 && what the heck does this do?
>>
>>Time for an extremely stupid question -- is there any particular reason why you have
>>SET CENTURY TO 20
>>instead of
>>SET CENTURY TO 19
>
>Thanks. It seems that this was the solution to the riddle. Setting it to 19, I get the correct date. Why the setting is so, I have no idea - Visual ProMatrix set it automatically. (Nor do I have any clear idea why, according to Visual FoxPro, I should set century to 19, when we are actually in the 21st century...)

From my Tips and Thanks page of my web site


The Y2K issue is not only a problem now, but also when our application are running in the 21 Century. For example, if a user enters a birth date of 6/10/60, the system should assume 1960, not 2060. But if they enter a birth date for new baby born on 6/10/01, it should assume 2001, and not 1901. VFP 5.0 and 6.0 have a ROLLOVER clause on the SET CENTURY statement to control this, but the value applied is the year the rollover occurs, and not the number of years into the future it should apply. The following line resolves this oversight. It keeps the rollover, in this case, ten (10) years beyond the current year.

#DEFINE kCentury 10
SET CENTURY TO 19 ROLLOVER MAX(0,(YEAR(DATE())+kCentury)-2000)