8
|
|
8 |
|
|
The LA Fox Developer Newsletter
|
|
July
1999
|
|
Y2K Support in FoxPro
(Con’t from page 7)
DateTime) field.
All versions of FoxPro provide a Date field type. All versions of
Visual FoxPro also provide a DateTime field type. FoxPro stores
Date type fields in a YYYYMMDD format as shown in Figure 1:
Figure 1. Data type storage differences
Date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or any input masks you might have on a textbox for data entry to a date field. This ensures that full, unambiguous dates are stored independent of application logic.
Dates Stored in Code
In the Date column of Figure 1, you see how it is possible to store ambiguous date information in code. Applications may not correctly interpret a value. In the case of a value such as “02/16/ 56”, FoxPro and \‘isual FoxPro do not know if the year refers to
1956 or 2056 (or even 1856)
and
must therefore make an assumption based on various settings
Additionally, one could have a date such as “01/02/56” in which the day and month are not easily determined. In the case of “0 1/02/56”, the format could either be mm/dd/yy or dd/mm/yy. Because of this, functions such as YEARQ, MONTHQ, CTOD(
)
and CTOT(
)
are susceptible to date ambiguities.
Dates are stored in code as they are entered. There are several ways to enter dates in code.
Dates entered as strings
The following example shows how a date may exist in code
when stored hard-coded as a string:
myDate “02/01156”
This is not a recommended way to store a date in code. Your application needs to handle this value appropriately for the application, and cannot rely on features such as System Regional settings.
In fact, dates stored in the above format are often converted for comparison against Date or DateTime fields as in the following example:
myDate
=
“02101I56”
IF cTOD(myDate)> myDateField ENDF
|
Avoid this approach to storing dates in code, as there are better ways to store dates. Some are described below.
Dates entered as dates
When you need to store hard-coded dates in Visual FoxPro,
use the Date curly braces
{ }
as shown in this example:
myDate
=
(02/01156)
When you use the Date curly braces, the value is interpreted as a date, so Visual FoxPro stores the full date, including a 4-digit year, in compiled code: The value is set at compile time and not runtime. In the preceding code, notice that there is only a 2-digit year date. When this date is compiled, FoxPro must make an assumption about which 4-digit year date to store.
The year that FoxPro assumes for a compiled date is based on the value of SET CENTURY. The full syntax for SET CENTURY in Visual FoxPro 6.0 is:
SET CENTURY ON
I
OFF
I
TO (nCentury [ROLLOVER nYearfl
Over the years, FoxPro has added new features to this command, so that ambiguous years in dates stored in code can be interpreted even more easily in the way you wish.
fEd.Note: This article was excerpted from ulargerarticle,
written
by Robert Green and
published
the ntemct. This article, too long to re-print in this
newsletter
because of space
A cynic is a man who, when he smells flowers, looks around for a coffin.
—H.L. Mencken (1 880-1 956)
It Can’t Get Any Easier.......
We’ve come up with an easy way to submit articles to the
LA
Fox Developer Newsletter
one that has been overlooked for
a long time.
You can submit your articles to Barry Lee at CIS# 72723,3422 on Compuserve,
or brlee@earthlink.net.
These articles can be on any FoxPro-related topic, whether it concerns a new technique you’ve discovered, a certain development technique you may favor over others, book reviews, etc. Editor reserves the right to edit or offer constructive comments concerning submitted articles and accepted articles shall be considered to be in the public domain.
The quality of this newsletter really depends on the members that support it, not just read it. And I think we’d all be surprised by the useful information that could be circulated around the membership.
|
|
Page 8
|
|
|
8 |
|