Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Win some, lose some
Message
From
15/05/1998 08:49:34
Ryan Hirschey
Federal Reserve Bank of New York
New York City, New York, United States
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00099618
Message ID:
00099691
Views:
19
>>As you'll see, VFP is fully Y2K compliant, as long as set century is used properly. I've posted an example that also makes entering only two digit years use the proper century. The message was posted on Saturday, and the code refined after some feedback.
>
>Yes, we're fully Y2K compliant on current vfp dates. I guess the gist of the article is that vfp6 dates will actually store the entire century, so that ROLLOVER will not be necessary...but my dates already appear to do this, that's what confuses me...perhaps they're confusing vfp and pre-vfp dates?

VFP already stores the entire century. The help file states that "A Date value is stored in “yyyymmdd” character format." I believe that FoxPro prior to VFP also stored 4-digit years. In fact, VFP can use dates through the year 9999! Rollover really is more for those situations when people key in two-digit years or when two-digit years are displayed. I always show four-digit years in my apps. Rollover tells VFP what century it should store in the field. The example I posted will read the current system date and put that in when a user enters 2-digit years.

Try this:

SET CENTURY TO VAL(LEFT(DTOS(DATE()),2))

To test it out:
1. Change your system date to 20xx
2. Type the following into your command window

SET CENTURY TO VAL(LEFT(DTOS(DATE()),2))
? {02/16/56} && Displays 02/16/2056

3. Change your system date back to 19xx
4. Type the following into your command window

SET CENTURY TO VAL(LEFT(DTOS(DATE()),2))
? {02/16/56} && Displays 02/16/1956

I'm not sure, but I think the 'new' Y2K features in VFP are for dates that are retrieved from other sources (i.e. not stored in VFP tables). It apparently can trap date values from legacy databases and allow some level of error handling and date correction so that VFP uses the dates properly in sorting, calculating, etc. Note that this then is really not a problem with VFP, but an extension that allows VFP to more intelligently handle non-compliant dates from other sources. Check out http://pubs.cmpnet.com/iw/newsflash/nf681/0513_st6.htm for another VFP article that more accurately (I hope!) describes the feature.
Ryan Hirschey
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform