Considere o seguinte:
declare @dt datetime, @dt2 datetime2, @d date
set @dt = '2013-01-01'
set @dt2 = '2013-01-01'
set @d = '2013-01-01'
select convert(varbinary, @dt) as dt,
convert(varbinary, @dt2) as dt2,
convert(varbinary, @d) as d
Resultado:
dt dt2 d
------------------ -------------------- --------
0x0000A13900000000 0x07000000000094360B 0x94360B
Agora, já entendi pela documentação que datetimetem um intervalo menor e começa em 1753-01-01, enquanto datetime2e dateusa 0001-01-01 como data de início.
O que eu não entendo, porém, é que datetimeparece ser little-endian while datetime2e datebig-endian. Se for esse o caso, como eles podem ser adequadamente classificáveis?
Considere se eu quero saber quantos dias inteiros são representados por um datetipo. Você pensaria que poderia fazer isso:
declare @d date
set @d = '0001-01-31'
select cast(convert(varbinary, @d) as int)
Mas devido ao endianness, você obtém 1966080 dias!
Para obter o resultado correto de 30 dias, você deve invertê-lo:
select cast(convert(varbinary,reverse(convert(varbinary, @d))) as int)
Ou, claro, você pode fazer isso:
select datediff(d,'0001-01-01', @d)
Mas isso significa que internamente em algum lugar está revertendo os bytes de qualquer maneira.
Então, por que eles trocaram o endianness?
Eu só me importo porque estou trabalhando em um UDT personalizado no SQLCLR e a ordem binária dos bytes parece importar lá, mas esses tipos integrados parecem muito mais flexíveis. O SQL Server tem algo interno onde cada tipo consegue fornecer seu próprio algoritmo de classificação? E, em caso afirmativo, existe uma maneira de aproveitar isso para meu UDT personalizado?
Veja também uma questão relacionada (mas diferente) no StackOverflow.