Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Year 2000 problem
Message
From
24/10/1997 09:07:27
 
 
To
24/10/1997 06:50:21
Matt Mc Donnell
Mc Donnell Software Consulting
Boston, Massachusetts, United States
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00056343
Message ID:
00056513
Views:
38
>>>>>>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
>>
>>Why not:
>>
>>lnCent=INT(year(date())/100)
>>lnRoll=MOD(year(date()),100)
>>
>>IF lnRoll < 30  &&  correct for first 30 years in century
>>   lnCent = lnCent-1
>>   lnRoll = 100 - lnRoll
>>ENDIF
>>
>>IMHO, it's a little more clear.
>>
>>>
>>>  SET CENTURY TO (lnCent) ROLLOVER (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. :-)
>
>Well Paul, that's nifty. I like that. But you missed the logic a bit.
>
>This is what it would be using your calculation
>
>lnCent=INT(year(date())/100)
>lnRoll=MOD(year(date()),100)-30  && start the window 30 years prior to today
>
>*- correct for century since prior century entries are still possible
>IF lnRoll < 0
>   lnCent = lnCent-1
>   lnRoll = lnRoll + 100
>ENDIF
>
>Thanks Paul.

Correct! :)

Vlad
Previous
Reply
Map
View

Click here to load this message in the networking platform