Expansion depends on when the application was executed and how accurate the system clock and calendar settings are. Check your system settings to avoid wrong expansion.
Specifies how to expand DATE and DATETIME values which were abbreviated to one or two digits.
Syntax:
DBCENTURY={R, C, F, P}
Possible values:
|
R (default) |
= current – value is prefixed with the digits of the current century |
|
C |
= closest – value is expanded to the nearest date in a past, future, or current century |
|
F |
= future – value is expanded to the nearest date which is definitely in the future |
|
P |
= past – value is expanded to the nearest date which is definitely in the past |
Usage and examples:
Years entered as two digits are expanded as shown in the examples below:
|
DBCENTURY=R (or not set) |
Current date: 1/15/2017 User enters: 1/10/17 Current century prefix – 20: 1/10/2017 Obtained expansion: 1/10/2017
|
Current date: 1/15/2017 User enters: 1/20/17 Current century prefix – 20: 1/20/2017 Obtained expansion: 1/20/2017 |
|
DBCENTURY=P |
Current date: 1/15/2017 User enters: 1/10/17 Current century prefix – 20: 1/10/2017 Nearest past century prefix – 19: 1/10/1917 Logics: Both variants are definitely in the past, but 1/10/2017 is closer to the current date. Resulting expansion: 1/10/2017
|
Current date: 1/15/2017 User enters: 1/20/17 Current century prefix – 20: 1/20/2017 Nearest past century prefix – 19: 1/20/1917 Logics: Only one variant is definitely in the past, 1/20/1917. Resulting expansion: 1/10/1917 |
|
DBCENTURY=F |
Current date: 1/15/2017 User enters: 1/10/17 Current century prefix – 20: 1/10/2017 Nearest future century prefix – 21: 1/10/2117 Logics: Only one variant is definitely in the future, 1/10/2117. Resulting expansion: 1/10/2117
|
Current date: 1/15/2017 User enters: 1/20/17 Current century prefix – 20: 1/20/2017 Nearest future century prefix – 21: 1/20/2117 Logics: Both variants are definitely in the future, but 1/20/2017 is closer to the current date. Resulting expansion: 1/20/2017 |
|
DBCENTURY=C |
Current date: 1/15/2017 User enters: 1/10/17 Current century prefix – 20: 1/10/2017 Nearest past century prefix – 19: 1/10/1917 Nearest future century prefix – 21: 1/10/2117 Logics: Of the three, 1/10/2017 is closest to the current date. Resulting expansion: 1/10/2017
|
Current date: 1/15/2017 User enters: 1/20/17 Current century prefix – 20: 1/20/2017 Nearest past century prefix – 19: 1/20/1917 Nearest future century prefix – 21: 1/20/2117 Logics: Of the three, 1/20/2017 is closest to the current date. Resulting expansion: 1/20/2017 |
|
Current date: 1/15/2017 User enters: 1/15/97 Current century prefix – 20: 1/15/2097 Nearest past century prefix – 19: 1/15/1997 Nearest future century prefix – 21: 1/15/2117 Logics: Of the three, 1/15/1997 is closest to the current date. Resulting expansion: 1/15/1997 |
Current date: 1/15/2097 User enters: 1/15/17 Current century prefix – 20: 1/15/2017 Nearest past century prefix – 19: 1/15/1917 Nearest future century prefix – 21: 1/15/2117 Logics: Of the three, 1/15/2117 is closest to the current date. Resulting expansion: 1/15/2117 |
Years entered as a single digit are first expanded to two digits by prefixing them with 0 and only then – to four digits by DBCENTURY.
Years entered as three digits are not expanded.
Years before 99 AD (or CE) require leading zeros to avoid expansion.
P and F cannot return the current date, as it is neither in the past nor in future.
DBCENTURY applies at runtime, so it must be set in inet.env.
If the database server and the client system have different settings for DBCENTURY, the client system settings precede over the database server.
Expansion depends on when the application was executed and how accurate the system clock and calendar settings are. Check your system settings to avoid wrong expansion.
Related articles: