SQL date conversion 19s instead of 20s

Question

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?

Answer 1

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.