Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Year2000 Problem
Message
From
23/10/1997 14:44:41
Matt Mc Donnell
Mc Donnell Software Consulting
Boston, Massachusetts, United States
 
 
To
23/10/1997 12:21:56
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00056373
Message ID:
00056403
Views:
27
>>>>Because of the Year 2000 transition , Foxpro will not face any problem. Am I right?
>>>>If any possible problems that could come because of Year2000. Please do suggest me
>>>>
>>>>You can mail to me at 'spvedulla@hotmail.com'
>>>
>>>Intrinsically, no. FoxPro has been Y2K ready for a while now. Even better in 5.0 with the inception of the ROLLOVER.
>>>
>>>The only thing you really need to be careful of is you will have date entries that span more than 99 years (i.e. on record with 10/10/1965, another with 10/10/2070), hence the rollover won't work for you and you'll need 10 digit date fields instead of 8.
>>
>>
>>Could you enlighten me more on this 99 mystery ?
>
>On second thought, it should be 100, but to clarify:
>
>I use the following function:
>
>
>FUNC f_Y2Kfix
> LOCAL lnCent, lnRoll
>
> lnCent=VAL(LEFT(allt(str(year(date()))),2))
> lnRoll=VAL(RIGHT(allt(str(year(date()))),2))-30
>
> IF lnRoll
>
>
>
>When run at the beginning of the app, I end up with a 100 year window, starting 30 years prior to today, which Foxpro will translate date entries with an 8 digit field. Hence for today:
>
>07/31/70 = 07/31/1970
>
>07/31/66 = 07/31/2066
>
>
>I've TOLD VFP that I don't expect any date entries to be more than 30 years in the past or more than 70 years in the future. So it translates the entries accordingly and I can use 8 digit fields ok. But if my expected entry window were MORE than 100 years, THEN I would need to use 10 digit fields. I hope that makes sense.
>
>I sure my apps won't be around in 50 years, but then, that's what all the COBOL programmer's thought in the 60s and 70s. :-)
>-----------------
>Does that mean It will change the system date?
>Alas I didnot understand even now also, Could you Please explain elobarately ?

No, VFP does not and cannot change the system date (at least not without an API call).

SET CENTURY 19 ROLLOVER 70 tells VFP how to interpret data entry. Therefore, when the user types: 10/17/75, VFP interprets it as 10/17/1975 and stores it in the table that way.

When the user types: 10/17/25, VFP interprets it as 10/17/2025. The 70 is the ROLLOVER year meaning if the year ends in a number hihger than that, use the current century, if the year is lower, then use the next century.

HTH
Matt McDonnell
...building a better mousetrap with moldy cheese...
Previous
Reply
Map
View

Click here to load this message in the networking platform