I have run into a SQL snippet including date conversion with 6 digits in the format of YYMMDD
.
SELECT CONVERT(DATETIME, '6011' + '01') AS testingdate
Why doesn't the followed query yield 2060-11-01
while '2011' + '01'
yields 2020-11-01
?
As @Squirrel commented, behavior for interpreting ambiguous 2-digit years is controlled by the 2 digit year cut-off configuration value . The value specifies an integer from 1753 to 9999 that represents the cutoff year for interpreting two-digit years as four-digit years, with a default configuration value of 2049.
The code below shows the behavior with default and custom 2 digit year cut-off values.
EXEC sp_configure 'show',1;
RECONFIGURE;
--default behavior: 2-digit years <= 49 use 20 as the century and > 49 use 19
EXEC sp_configure 'two digit year cutoff',2049;
RECONFIGURE;
GO
SELECT CAST('01-01-49' AS date); --2049-01-01
SELECT CAST('01-01-50' AS date); --1950-01-01
GO
----custom behavior: 2-digit years <= 49 use 19 as the century and > 49 use 18
EXEC sp_configure 'two digit year cutoff',1949;
RECONFIGURE;
GO
SELECT CAST('01-01-49' AS date); --1949-01-01
SELECT CAST('01-01-50' AS date); --1850-01-01
GO
----custom behavior: 2-digit years <= 49 use 21 as the century and > 49 use 20
EXEC sp_configure 'two digit year cutoff',2149;
RECONFIGURE;
GO
SELECT CAST('01-01-49' AS date); --2149-01-01
SELECT CAST('01-01-50' AS date); --2050-01-01
GO
--revert to recommended default value
EXEC sp_configure 'two digit year cutoff',2049;
RECONFIGURE;
GO
2-digit year cut-off is a kludge work-around for short-sighted programming practices of the past, IMHO. I suggest one follow the recommendation from the referenced documentation page so that ancestors don't inherit a Y2.1K problem:
To avoid ambiguity with dates, always use four-digit years in your data.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.