datetimeno Adaptive Server Enterprise (e no SQL Server, pois compartilham uma base de código comum que inclui o tipo datetime) é armazenado usando 8 bytes. 4 bytes para a data e 4 bytes para a hora. Você pode ver isso observando a versão binária de um datetime:

SELECT CONVERT(varbinary(8), CONVERT(datetime, '1753-01-01T00:00:00.000'), 0)
SELECT CONVERT(varbinary(8), CONVERT(datetime, '1900-01-01T00:00:00.000'), 0)
SELECT CONVERT(varbinary(8), CONVERT(datetime, '1900-01-02T00:00:00.000'), 0)
SELECT CONVERT(varbinary(8), CONVERT(datetime, '3000-12-31T23:59:59.997'), 0)

Os quatro valores binários são:

0xFFFF2E4600000000
0x0000000000000000
0x0000000100000000
0x000622D3018B81FF

Veja o seguinte, que mostra onde o 1/300 de segundo entra em jogo:

SELECT CONVERT(varbinary(8), CONVERT(datetime, '1900-01-01T00:00:00.000'), 0) 
SELECT CONVERT(varbinary(8), CONVERT(datetime, '1900-01-02T00:00:00.000'), 0) 
SELECT CONVERT(varbinary(8), CONVERT(datetime, '1900-01-02T00:00:00.003'), 0) 

A diferença entre o 2º e o 3º valores, é uma:

0x0000000000000000
0x0000000100000000
0x0000000100000001

Assim, as datas são armazenadas nos 4 bytes mais significativos; e os tempos são armazenados nos 4 bytes menos significativos. Embora mover para uma precisão maior que 3 milissegundos (1/300 de segundo) seja possível em 4 bytes de armazenamento; essa é toda a precisão que é realmente usada.

No SQL Server, você pode usar um datetime2(7)tipo de dados para obter precisão de até 7 dígitos, com precisão de 100ns:

SELECT CONVERT(varbinary(16), CONVERT(datetime2(7), '1900-01-01T00:00:00.0000000'), 0)
SELECT CONVERT(varbinary(16), CONVERT(datetime2(7), '1900-01-01T00:00:00.0000001'), 0)
SELECT CONVERT(varbinary(16), CONVERT(datetime2(7), '1900-01-01T00:00:00.0000002'), 0)

O armazenamento desses valores é um pouco diferente, mas você ainda pode ver o valor binário aumentando:

0x0700000000005B950A
0x0701000000005B950A
0x0702000000005B950A

Estou usando o cliente Sybase ISQL; Utilitário Sybase CTISQL/15.7/P-EBF20996 SP100/DRV.15.7.0.10

datetimeComo um aparte, existe uma pequena diferença entre os valores de arredondamento do Adaptive Server Enterprise (ASE) e do SQL Server . No SQL Server, milissegundos são arredondados para 0.000,0.003 e 0.007, enquanto no ASE eles são arredondados para 0.000, 0.003e 0.006- por que há uma diferença não está documentada até onde eu sei. Você pode ver isso no ASE executando esta consulta:

SELECT CONVERT(varchar(50), CONVERT(datetime, N'2017-01-01T23:59:59.997'), 139);

Que retorna:

Jan  1 2017 23:59:59.996000

Enquanto no SQL Server, o código equivalente,SELECT CONVERT(varchar(50), CONVERT(datetime, N'2017-01-01T23:59:59.997'), 109); , retorna:

Jan  1 2017 11:59:59:997PM

Com base nessa resposta , fica claro que a codificação exata é opaca e contra-intuitiva. Também está claro que a declaração na documentação do Sybase no sentido de que datetimepode conter valores accurate to 1/300 secondé enganosa e imprecisa.

O que a documentação deveria ter dito é que datetimetem uma resolução/precisão/granularidade (escolha seu termo favorito) de aproximadamente 1/300 de segundo ou aproximadamente 3 ms .

Fiz um teste para confirmar isso. Em uma mesa com aproximadamente 1000datetime valores (gerados aleatoriamente, pois dependem da entrada do usuário), eu queria ver quantos valores distintos de milissegundos eu encontraria:

 SELECT COUNT(*) FROM
 (
   SELECT DISTINCT y.millis FROM
   (
      SELECT RIGHT(RTRIM(LTRIM(x.submissionDate)), 6) AS millis FROM (
         SELECT convert(char(32), submission_date, 139) AS submissionDate FROM someTable
      ) x
   ) y
 ) z

A instrução SQL mais interna na consulta acima também foi usada na minha pergunta e produz os valores que publiquei na minha pergunta.

O resultado da consulta composta foi 237, o que é consistente com o acima.

Além disso, a documentação do SQL Server (que é aplicável, pois a datetimeimplementação faz parte da base de código compartilhada entre o Sybase ASE e o SQL Server), diz o seguinte:

Segue imagem:

Na mesma página é ainda assinalado que:

datetime não é compatível com ANSI ou ISO 8601.

No geral, acho que usar um tipo tão peludo é um antipadrão. Não consigo entender por que alguém simplesmente não usaria um INTpara armazenar segundos desde a Epoch (sim, eu sei sobre 2038), ou a BIGINTpara armazenar milissegundos ou mesmo microssegundos ou nanossegundos desde a Epoch.

atualização após testes exaustivos

Consegui encontrar algum tempo para fazer testes exaustivos sobre esse assunto e consegui chegar ao fundo disso. Aqui estão minhas descobertas (testadas em relação ao Sybase ASE 15.7, acho que os mesmos resultados se aplicam ao SQL Server):

Provei experimentalmente que o servidor mantém Datetimevalores fornecidos a ele pelo cliente com resolução de 1/300 de segundo. Criei uma tabela com o seguinte DDL:

DROP TABLE DatetimeTest;
CREATE TABLE DatetimeTest (
    d DATETIME NOT NULL
);

… e preenchê-lo (usando um programa de driver em Java) com 1000 valores com incrementos de milissegundos de 1/1000 de segundo. Executando a seguinte consulta:

 SELECT COUNT(*) FROM
 (
 SELECT DISTINCT y.millis FROM
 (
 SELECT RIGHT(RTRIM(LTRIM(x.d)), 6) AS millis FROM (
 SELECT convert(char(32), d, 139) AS d FROM DatetimeTest
 ) x
 ) y
 ) z                                                  

… rendeu exatamente 300.

O acima estabelece que o servidor é capaz de armazenar apenas 300 valores distintos para a segunda parte fracionária. Isso não prova que os valores reais mantidos são múltiplos de 1/300 de segundo, mas é uma indicação razoável.

O que o acima implica é que qualquer armazenamento de segundos fracionários fornecido pelo cliente ao servidor é potencialmente com perdas. Portanto, fiz alguns testes adicionais para estabelecer exatamente o quão com perdas. O que encontrei é o seguinte:

• valores de tempo com segunda precisão no cliente podem ser armazenados sem perdas no servidor (tudo bem, nunca houve dúvidas sobre isso)
• valores de tempo com precisão de décimo de segundo no cliente podem ser armazenados sem perdas no servidor
• valores de tempo com precisão de centésimos de segundo no cliente podem ser armazenados sem perdas no servidor
• apenas 10% dos valores de tempo com precisão de milissegundos no cliente podem ser armazenados sem perdas no servidor (os correspondentes a centésimos de segundo completos). Para os 90% restantes dos valores pode-se observar uma diferença entre o que o cliente forneceu e o que o servidor armazenou até (e inclusive) 3ms.

O acima é consistente com a hipótese do servidor armazenar o componente de tempo como um número inteiro de 1/300s de segundo como:

• qualquer décimo de segundo valor pode ser expresso exatamente como uma fração na forman/300
• qualquer centésimo de segundo valor pode ser expresso exatamente como uma fração na forman/300
• apenas 10% dos possíveis valores de milissegundos podem ser expressos exatamente como uma fração na forma n/300.

Por fim, fica claro que há algo errado com a convertfunção conforme a consulta:

SELECT convert(char(32), d, 139) AS d FROM DatetimeTest

… relata zeros além do terceiro ponto decimal, o que claramente não é correto e confuso. Mas não acredito que refute o que foi dito acima.

atualização II

Estranhamente, a porcentagem relatada pelo meu código de teste para mapeamentos de servidor não exatos para valores de milissegundos é de 90% apenas quando uso em meus testes o driver Sybase jConnect JDBC . Para o driver JTDS JDBC de código aberto, aplicam -se 70% aprimorados e maravilhosamente redondos. Basicamente, a lógica de teste é que eu crio um valor com precisão de milissegundos no lado do cliente, armazeno-o no servidor e, em seguida, leio-o novamente do cliente para ver o que recebo. Esse arranjo de teste permite que o driver do lado do cliente corrija suavemente alguns valores do servidor no caminho de volta (quando o código do lado do cliente for lido no banco de dados).

Aparentemente, o driver JTDS pode explicar de maneira mais inteligente a maneira idiossincrática em que o servidor Sybase armazena o segundo componente fracionário e pode fazê-lo para todos os 300 valores distintos do servidor (compensando o erro de arredondamento na direção reversa - do servidor para o cliente - conforme necessário), não apenas para aqueles 100 que correspondem exatamente a algum valor de milissegundo na faixa de 0-1000.

De qualquer forma, isso não altera os fatos no lado do servidor e só é relevante se houver controle sobre o idioma e o driver do lado do cliente que serão usados ​​para extrair Datetimevalores do servidor.

Pensei em pular essa parte para manter as coisas simples, mas então pensei em adicioná-la para completar. Também corrobora o modelo de armazenamento de Datetimevalores do servidor, pois todos esses números (300, 90%, 70%) se encaixam na narrativa. Mas a vida é muito curta, hora de seguir em frente.