Entiers d'époque et colonnes d'horodatage : pourquoi l'unité appartient au schéma Bases de données

créé_à : 1700000000 ou 1700000000000 ? — la chronique que deux services ont écrite dans des unités différentes pendant six mois

Une colonne appelée `created_at` contenant à la fois 1,738,578,000 et 1,738,578,000,000 ne peut pas être interprétée de manière cohérente. Le tri sépare numériquement les auteurs par échelle plutôt que par chronologie, et la détection automatique dans chaque lecteur masque la corruption au lieu de la réparer. Le schéma n'a pas réussi à conserver une unité requise.

Avant la migration, profilez les valeurs par producteur et comparez les lignes représentatives avec des preuves d'événements indépendantes. Ne divisez pas aveuglément toutes les valeurs longues ; une colonne mixte nécessite une provenance ou une classification soigneusement délimitée. ToolAcre aide à inspecter les échantillons mais ne déduit pas quel service a écrit chaque ligne.

Des magnitudes mixtes peuvent également fausser les index et les requêtes de rétention avant que quiconque n'ouvre une ligne. Traitez la découverte comme un incident d’intégrité des données, et non comme un simple défaut de formatage chez un client.

Les arguments en faveur des époques entières : portabilité, tri, arithmétique et indépendance par rapport aux paramètres de fuseau horaire de la base de données

Une époque entière est compacte à échanger et simple à comparer lorsque l'origine, l'unité et la largeur sont fixes. Il évite le stockage de texte formaté en fonction des paramètres régionaux et prend en charge l'arithmétique de durée après normalisation. Ces avantages proviennent d'un contrat autour du numéro, et non d'INTEGER en lui-même.

Les coûts apparaissent lorsque ce contrat est absent : les humains ne peuvent pas lire la valeur directement, un client générique peut arrondir de grands entiers et un type de colonne ne dit rien sur les secondes par rapport aux millisecondes. Ajoutez un suffixe d'unité ou une description de schéma et validez les rédacteurs à la limite.

Un contrat entier doit également indiquer l'arrondi pour une entrée inférieure à la seconde. L'étagement, la troncature ou l'arrondi peuvent attribuer des événements limites à différentes secondes, même lorsque l'échelle est par ailleurs correcte.

Les époques entières offrent un échange numérique simple, avec des compromis déterminés par le schéma environnant

Un type temporel natif de base de données peut exposer des opérations de date lisibles et rejeter certaines entrées non valides, mais la plage, la sémantique du fuseau horaire et le rendu client varient selon le moteur et le type. Le référentiel d'horodatage ne contient aucun adaptateur de base de données, il ne peut donc pas classer ces produits ni garantir la « connaissance » d'un nom de type générique.

Lisez la documentation actuelle du moteur choisi et testez le pilote. Certains clients peuvent renvoyer des chaînes, des objets Date ou des valeurs ajustées en fonction de la zone. Un type natif réduit certaines ambiguïtés uniquement lorsque le type exact et le comportement de la session sont compris ; ce n’est pas un substitut universel à un modèle temporel d’application.

Le comportement de l'horodatage natif est spécifique à la base de données et doit être vérifié dans ce moteur

Un entier signé étroit et un entier large ont des plages différentes, mais la largeur ne code toujours pas l'échelle. Un BIGINT peut contenir en toute sécurité plusieurs millisecondes tout en restant sémantiquement anonyme. À l’inverse, un champ de 32-bit secondes s’approche d’une limite connue même si ses valeurs semblent ordinaires aujourd’hui.

Les commentaires revendiqués dans le classeur sont le seul enregistrement, qui est trop absolu. Les noms, types de domaines, contraintes, schémas générés et spécifications API peuvent tous porter l'unité. Utilisez plusieurs couches exécutoires. Les commentaires humains aident les réviseurs, tandis que le code et la validation empêchent un rédacteur de changer d'échelle en silence.

La largeur et l'unité du champ sont des décisions de schéma indépendantes

Supposons qu'une ligne créée lors d'un déploiement 2025 connu contienne `1738578060000`. En millisecondes, cela devient `2025-02-03T10:21:00.000Z` ; en secondes, il dépasse les attentes ordinaires et peut dépasser la fourchette du consommateur. Une ligne voisine `1738578060` correspond au même instant que les secondes.

Cette paire suggère des unités mixtes mais ne prouve pas quels écrivains sont responsables. Regroupez par version de service, chemin d’ingestion ou ampleur, puis vérifiez plusieurs événements connus. Conservez les sauvegardes et les journaux de migration. Le convertisseur est une lentille d’audit, pas un moteur de réécriture en masse.

Auditez plusieurs dates au cours de la période concernée. Une correspondance fortuite peut être trompeuse, alors qu’un modèle cohérent spécifique à un producteur soutient une règle de migration contrôlée.

Exemple pratique : déterminer l'échelle d'une colonne héritée suspecte à partir d'enregistrements connus

Empêchez la récurrence en nommant les champs bruts `created_at_s` ou `created_at_ms`, en analysant sur un adaptateur et en exposant un seul type instantané interne. Stocker les instants UTC ; appliquer la présentation locale uniquement sur les bords orientés vers l'utilisateur. Si une valeur API textuelle est préférable, exigez un décalage explicite ou Z.

Les tests doivent envoyer des valeurs distinctes à travers chaque limite de sérialisation. Zéro est un mauvais résultat car les deux échelles concordent. Affirmez un instant ISO fixe et effectuez un aller-retour via le pilote réel. Cela détecte la perte d'unité avant que deux services ne remplissent différemment une colonne pendant des mois.

Pendant la migration, rejetez les nouvelles écritures qui violent le contrat choisi avant de réparer les anciennes lignes. Sinon, le nettoyage génère une source active qui continue de créer des données mixtes.

Ce que cela ne couvre pas : les fonctions spécifiques à la base de données telles que FROM_UNIXTIME et to_timestamp, qui varient selon le moteur

Cet article ne prescrit pas `FROM_UNIXTIME`, `to_timestamp` ou des fonctions équivalentes. Leurs unités d'entrée, plages et interactions de zones appartiennent à des moteurs et versions spécifiques, dont aucun ne fait partie de l'implémentation de ToolAcre. Copier un nom de fonction dans des bases de données peut créer l'ambiguïté même à l'étude.

Utilisez la documentation du fournisseur et un tableau jetable pour prouver les conversions avant une migration. Empêchez les transformations d'application et de base de données d'appliquer le même décalage ou le même facteur. Une seule conversion bien détenue est plus facile à tester qu’une chaîne de conversions implicites.

Exécutez la fonction de base de données sur les appareils de limite dans les mêmes paramètres de session que la production. Les valeurs par défaut de la zone de session peuvent modifier les résultats textuels même lorsque l'arithmétique d'époque est correcte.

À retenir : le schéma est l'endroit où réside l'unité - et comment le convertisseur d'horodatage Unix vous aide à auditer les données existantes en indiquant l'unité qu'il a appliquée

Le schéma doit rendre la représentation d'un horodatage sans surprise pour chaque écrivain et lecteur. Les nombres entiers peuvent être appropriés ; des colonnes temporelles natives peuvent être appropriées. Une échelle sans nom ne l’est pas. Choisissez un contrat, appliquez-le et traitez la conversion comme une opération de limite explicite.

Pour les données existantes, inspectez les échantillons sous les deux unités, corrélez-les avec des événements connus et enregistrez l'incertitude. La sélection d'unités visibles de ToolAcre prend en charge cette enquête, mais la décision finale de migration doit provenir de la provenance et de la sémantique réelle de la base de données.

Une révision de schéma n'est terminée que lorsque les rédacteurs, les lecteurs, les index et les tâches de rétention partagent le même modèle. La correction du commentaire de la colonne laisse seule l'ambiguïté de l'exécutable.