921 Date & Time: DatesVERSIONS: Paradox 7 and 8
Read this carefully as it's on older versions of the BDE
Subject: Year entered as two digits or four digits
BY: DAN ALDER (COREL CORPORATION)
Date: 13 April 1999
Paradox 8 handles dates that use two-digit years in one fashion, they are assumed to be between 1951 and 2050, but this only applies to portions of the program that Paradox has full control over, namely direct input in forms and table views and ObjectPAL. Paradox 7 used a different algorithm - two digit years were assumed to be in the current century according to the system clock, I believe.
However, the BDE makes the assumption on almost all data-related functions, and it's not consistant. BDE 3.x generally used the current century; BDE 4.51 and 5.00 changed some, but not all, functions to a 1950-2049 window. QBE in everything before 5.01 uses 1900s always. Importing ascii fixed text, depending on how the dates are listed, sometimes assumes the first century BC (0000 - 0099).
In any case, the advice given previously is still the best - enter 4 digits always!
VERSIONS: P7-P8, BDE <= 4.51
Subject: BDE 4.x and dates
BY: RICHARD FAIRHURST
Date: 21 January 1999
Generally, Paradox 7 and prior should base their assumed century dates on the current system date (i.e., today all two digit years will fall between January 1, 1900 and December 31, 1999, but begining January 1, 2000 all two digit years will be assumed to be January 1, 2000 to December 31, 2099). Paradox 8 has two assumed century ranges that must be accounted for, a display range and an input range. The display range is the same as Paradox 7 and prior. The input range, however, is in a different range that won't change until the system date reaches January 1, 2051. Currently, that range assumes that all two digit dates fall between January 1, 1951 and December 31, 2050.
BDE version 4.51 and prior
First, your FOURDIGITYEAR setting is set to FALSE. When this is the setting, it doesn't matter what your display settings are. Anytime a date variable is translated to a query variable it is first converted to a string using the DBDate date format. With the BDE FOURDIGITYEAR setting set to FALSE the date variable is inserted into your query as a two-digit year date string if it falls within the current system date century. The YEARBIASED setting is obviously TRUE, however, the BDE is unfortunately true to its word and add 1900 to all two-digit year dates regardless of the system date.
Here is what was happening. When the system date was set to 1/21/1999, and you entered 1/21/00 or 1/21/2000, the value was first translated to the date variable as 1/21/2000 and then because this date did not fall in this century the DBDate format translated it to the query variable as a string with the full four-digit year. However, when you set your system date to 1/21/2000, the date variable always correctly stored the value as 1/21/2000, but the DBDate format translated it to the query variable as a two-digit year string of 1/21/00. The YEARBIASED behavior of the BDE then added 1900 to it, instead of 2000, since it does not respond to the system date like the rest of Paradox. Therefore, you get the result you got. I tried all combinations of FOURDIGITYEAR and YEARBIASED settings and these are the results I got with the system date set to 1/21/2000:
1) FOURDIGITYEAR = TRUE and YEARBIASED = TRUE Answer = 1/21/2000.
2) FOURDIGITYEAR = TRUE and YEARBIASED = FALSE Answer = 1/21/2000.
3) FOURDIGITYEAR = FALSE and YEARBIASED = TRUE Answer = 1/21/1900.
4) FOURDIGITYEAR = FALSE and YEARBIASED = FALSE Answer = nothing (it tried to match for 1/21/0000 because the date string was 1/21/00 and it didn't add anything to the two-digit year).
The only reliable setting for code is the first one. The second one gave the desired results in this case, but if a user inputted a two digit date string in an interactive query, they would not get any results unless they had entries in the years 0000 to 0099. The third and fourth settings give bad results as you can see.
Even using the first setting I agree that the YEARBIASED behavior is not truly Y2K compliant in the way that the rest of Paradox is, since unless the BDE is recoded it will forever lock two-digit in queries to years in this century. For code this can be easily overcome with the FOURDIGITYEAR setting and the use of real date variables instead of two-digit year date strings. However, this will confuse users of interactive queries who type a two-digit year in a query next century expecting to get dates between 1/1/2000 and 12/31/2099 (since that is what their date display settings of Paradox would probably lead them to think the two-digit year range is), but they will keep getting back dates between 1/1/1900 and 12/31/1999. I don't know if this addressed in BDE 5.0. The lesson, even for interactive queries is, always use four digit year strings if you want to always be sure you get the correct results.
Comments by: BRIAN BUSHAY
When I test with BDE 4.51 I get the same results as you do, so it is fixed in 5.01
Also You may want to look at adding this kind of code to your application startup to ensure a 4 digit year.
formatAdd("Year_4","DWSMSDSY3OS")
formatSetDateDefault("Year_4")