FOX 2.D and Y2K

[blazblaz]

Can somebody help me. I want to add a new record to file, and one of the field is type of DATE in my database. I am using format MM/DD/YY (Set century is not ON) I am using GET command to fill out the filed, like @ 10,20 GET mydate picture "D!", Replacing it in DBF file, the programs treats year 2002 as 1902. (later I set SET CENTURY ON, so I can see in file that the year is 1902). If I give an initial value for mydate=date() (todays date), finishing the edit and replacing field with the value in DBF file it's the right year, 2002. I want to use date as MM/DD/YY, but to not give an initial value, just live empty (so date does not need to be filled out in application). How to do it to get right year?

 

[Scott24x7]

Blazblaz,
You can "Validate" the year, in using a VALID clause in your @Get. Create a UDF called CNVTYEAR, that looks like this:

PROCEDURE CNVTYEAR
PARAMETER M.DATEVALUE

M.YEARVAL = RIGHT(DTOS(M.DATEVALUE),4)
*
IF VAL(RIGHT(M.YEARVAL,2)) < 55
M.NEWDATE = LEFT(DTOS(M.DATEVALUE),6)+'20'+;
RIGHT(M.YEARVAL,2)
M.YEARVAL = CTOD(M.NEWDATE)
ELSE
M.NEWDATE = M.DATEVALUE
ENDIF
*
RETURN M.NEWDATE

You'll notice that if it doesn't &quot;Match&quot; the year validity, then it just returns the value passed to it. Also, the check against &quot;55&quot; is basically saying, if the date is later than 1955, than makey it 2054 (or whaterver the year is) so this will convert dates from 1900 to 1954 to 2000 - 2054.

I just wrote this off the top of my head, so a couple of my CTOD or DTOS syntaxe's may not be perfect, but you are smart, and can figure that part out by taking a look at the help, in the event I've done something wrong!

Best Regards,
Scott

Please let me know if this has helped

 

[blazblaz]

Thanks Scott, I guess it will work, I try to change my program tomorrow.

 

[jschenke]

Hi blazblaz,

Here's the code I use for this sort of fun..
The added advantage to Scott's approach is that it works transparently for memory variables and database fields if you happen to have those directly on-screen.
Put the code below in a separate program file and set the 'valid' expression of your date fields to pDatY2K()

Best regards,

Jan Schenkel

&quot;As we grow older, we grow both wiser and more foolish at the same time.&quot; (De Rochefoucald)

---- Code snippet ----

PROCEDURE pDatY2K

** Define preprocessor variables
#DEFINE _c_Y2KBase 1960

** Define local variables
PRIVATE theObject, theDate
theObject = OBJVAR() && by default the current object
theDate = VAL(theObject)

** Change environment
PRIVATE theOldCentury
theOldCentury = SET('CENTURY')
SET CENTURY ON

** Do the grunt work
IF YEAR(theDate) < _c_Y2KBase
theDate = CTOD(STUFF(DTOC(theDate), 7, 2, &quot;20&quot)
ENDIF
IF LEFT(theObject, 2)=&quot;M.&quot; && a memory variable
STORE theDate TO &theObject
ELSE
REPLACE NEXT 1 &theObject WITH theDate
ENDIF

** Clean up and return
SET CENTURY &theOldCentury
RETURN .T. && as it is a valid date now

** Undefine preprocessor variables
#UNDEF _c_Y2KBase

 

[blazblaz]

Thanks guys, I used your recomendation, it's working. Though I still did not understand why FOX gives corerct year for DATE field, if I give initial value for date, (2002), and gives wrong if I leave initial value empty (1902). Anyway, i bypassed it, it's working now.

 

[jschenke]

Hi blazblaz,

When FoxPro 2.x was released back in 1992 (93?), the programmers weren't even thinking about Y2K issues -- and if they were, they figured you'd have updated your program with a later version by now

As it states in the documentation, the program will always assume the 20th century (19xx) when you enter a date -- that is, unless you have set century on, and type all 4 digits.
If you only type 2 digits, it assumes 19xx again.
When you use the DATE() function, Fox is a good boy and hands you today's date. But if you change the default date, he'll assume the rules above since he can't know for sure...

So technically, there's no Y2K incompatibility problem, it's just inconvenient that either the lazy kind of programmer simply sets the century on at the start of the main program, and leaves up to the end-user to type in all 4 digits ; or the supportive programmer has to develop and implement a workaround such as the ones above.

Oh well, there are bigger things to worry about

Jan Schenkel.

 

[xBaseDude]

Just to jump in and add my 2 cents.

There are also issues with the LUPDATE() command now.

I've never used it in code so it never bothered me, but it also falsely reports the 19nn year as when the dbf was last updated.

Regards - Wayne

 

[blazblaz]

Thanks Jan, I understand now the problem. I did not have much time to investigate, but i looks so easy now. I am using subprogram to convert the year, and it just works fine.

 

[Jerry4DOS]

Hi xBaseDude:
If you get 2¢, I get 2¢.
If you use the PROJECT MANAGER, click the INFO button and look at how FPD displays dates later than Y2K!
Jerry