Podemos fazer isso em vez disso:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
O
FROM_UNIXTIME função é limitada pelo intervalo permitido para o TIMESTAMP tipo de dados, que é o intervalo padrão sem sinal de 32 bits de 1970-01-01 a 2038-01-algo. Outro software foi atualizado para suportar inteiros assinados de 64 bits, mas o MySQL ainda não fornece essa funcionalidade (pelo menos não na versão 5.1.x). A solução alternativa no MySQL é evitar usar o
TIMESTAMP tipo de dados e usando o DATETIME datatype em vez disso, quando precisamos de um intervalo maior (por exemplo, datas anteriores a 1º de janeiro de 1970). Podemos usar o
DATE_ADD função para subtrair segundos de 1º de janeiro de 1970, assim:SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
N.B. Você provavelmente precisará levar em conta os "deslocamentos" de fuso horário do UTC ao fazer esses tipos de cálculos. O MySQL vai interpretar os valores DATETIME como especificados no
time_zone configuração da sessão MySQL atual, em vez de UTC (time_zone = '+00:00' ) ACOMPANHAMENTO:
P: Ok, significa que se selecionarmos datas abaixo de '1970-01-01 00:00:00', o valor negativo será salvo no banco de dados, caso contrário, seria positivo. Direita? - Genética suave
R: Ahhh, não. Se você selecionar valores date/datetime antes de 1º de janeiro de 1970, o MySQL retornará valores DATE ou DATETIME antes de 1º de janeiro de 1970. , 1970, dentro do intervalo permitido suportado por esses tipos de dados. (algo como 0001-01-01 a 9999?)
Se você precisar armazenar números inteiros positivos e negativos realmente grandes no banco de dados, você provavelmente os armazenaria em uma coluna definida como
BIGINT . A representação interna de uma coluna DATE requer 3 bytes de armazenamento e DATETIME requer 8 bytes de armazenamento (até o MySQL versão 5.6.4. A representação interna e armazenamento de valores DATE e DATETIME foram alterados em 5.6.4)
Portanto, não, o MySQL não armazena valores de data anteriores a 1970 como "inteiros negativos".
Se você pensar um pouco, o MySQL é livre para implementar qualquer mecanismo de armazenamento que desejar. (E cada mecanismo de armazenamento é livre para serializar essa representação no disco como quiser.)
Por que 3 bytes para uma data?
Uma opção que o MySQL tem (e não estou representando que é assim que é feito) poderia ser dividir a data em seus componentes ano, mês e dia.
A representação de valores inteiros no intervalo - requer -
-
0 - 9999 -14 bits
-
0 - 12 -4 bits
-
0 - 31 -5 bits
Isso é um total de 23 bits, que cabe facilmente em 3 bytes. Isso apenas demonstra que não é necessário que o MySQL represente valores de data antes de 1º de janeiro de 1970 como números inteiros negativos, então não devemos supor que sim. (Mas só estaríamos preocupados com esse nível de detalhe se estivéssemos trabalhando em um mecanismo de armazenamento para MySQL.)
