Nous pouvons faire ceci à la place :
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
Le FROM_UNIXTIME la fonction est limitée par la plage autorisée pour le TIMESTAMP type de données, qui est la plage standard d'entiers non signés 32 bits 1970-01-01 à 2038-01-quelque chose. D'autres logiciels ont été mis à jour pour prendre en charge les entiers signés 64 bits, mais MySQL ne fournit pas encore cette fonctionnalité (du moins pas dans la version 5.1.x).
La solution de contournement dans MySQL est d'éviter d'utiliser le TIMESTAMP type de données et en utilisant le DATETIME type de données à la place, lorsque nous avons besoin d'une plage plus large (par exemple, des dates antérieures au 1er janvier 1970).
Nous pouvons utiliser le DATE_ADD fonction pour soustraire des secondes du 1er janvier 1970, comme ceci :
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
N.B. Vous devrez probablement tenir compte des "décalages" de fuseau horaire par rapport à UTC pour effectuer ces types de calculs. MySQL va interpréter les valeurs DATETIME comme étant spécifiées dans le time_zone réglage de la session MySQL en cours, plutôt que UTC (time_zone = '+00:00' )
SUIVI :
Q : D'accord, cela signifie que si nous sélectionnons des dates en dessous de '1970-01-01 00:00:00', la valeur négative est enregistrée dans la base de données, sinon elle serait positive. À droite? – doux génique
R : Euh, non. Si vous sélectionnez des valeurs date/datetime avant le 1er janvier 1970, MySQL renverra les valeurs DATE ou DATETIME avant le 1er janvier 1970. Si vous stockez les valeurs DATE ou DATETIME avant le 1er janvier 1970, alors MySQL stockera la valeur DATE ou DATETIME avant le 1er janvier , 1970, dans la plage autorisée prise en charge par ces types de données. (quelque chose comme 0001-01-01 à 9999 ?)
Si vous avez besoin de stocker des entiers positifs et négatifs vraiment très gros dans la base de données, vous les stockerez probablement dans une colonne définie comme BIGINT .
La représentation interne d'une colonne DATE nécessite 3 octets de stockage et DATETIME nécessite 8 octets de stockage (jusqu'à MySQL version 5.6.4. La représentation interne et le stockage des valeurs DATE et DATETIME ont été modifiés dans 5.6.4)
Donc non, MySQL ne stocke pas les valeurs de date avant 1970 sous forme d'"entiers négatifs".
Si vous y réfléchissez un peu, MySQL est libre d'implémenter le mécanisme de stockage de son choix. (Et chaque moteur de stockage est libre de sérialiser cette représentation sur disque comme il le souhaite.)
Pourquoi 3 octets pour une date ?
Une option que MySQL a (et je ne prétends pas que c'est ainsi que cela se fait) pourrait être de diviser la date en ses composants année mois et jour.
La représentation des valeurs entières dans la plage - nécessite -
-
0 - 9999 -14 bits -
0 - 12 -4 bits -
0 - 31 -5 bits
C'est un total de 23 bits, qui tient facilement dans 3 octets. Cela démontre simplement qu'il n'est pas nécessaire que MySQL représente les valeurs de date avant le 1er janvier 1970 sous forme d'entiers négatifs, nous ne devrions donc pas supposer que c'est le cas. (Mais nous ne serions vraiment concernés par ce niveau de détail que si nous travaillions sur un moteur de stockage pour MySQL.)
