Pourquoi les horodatages ont-ils une limite à 2038?

Question

Je viens de découvrir, exécuter un script de calendrier, que les horodatages en PHP ont une limite à 2038. Qu'est-ce que cela signifie vraiment? Pourquoi est-ce 2038 au lieu de 2050 ou 2039? Pourquoi une limite si les horodatages ne comptent que des secondes à partir d'une date donnée (1970)?

Answer 1

La limite est imposée par les entiers signés de 4 octets que la plupart des bibliothèques C utilisent pour représenter ce nombre. MATH rapide (assume 365 ans, pas exactement correct):

2147483648 seconds ~ 68.1 years

Cela implique également une limite inférieure de ~ 1900. Certaines bibliothèques ont commencé à introduire des dénombrements d'époches 64 bits, mais ils sont rares pour le moment.

Answer 2

La valeur maximale d'un entier 32 bits est de 2 147 483 647. Si vous ajoutez +1 à cela, vous obtenez -2 147 483 647. 2 147 483 647 secondes du 01-01-1970 00:00:00 est le 19 janvier 2038. Si vous ajoutez une seconde de plus, vous obtenez une date quelque part en 1902.

Answer 3

En raison de la limite du type de données int sur une machine 32 bits

http://php.net/manual/en/fonction.mktime.php

Depuis php.net: "La date maximale possible acceptée par mktime () et gmmktime () dépend du fuseau horaire de localisation actuel.

Par exemple, le débordement de l'horodatage 32 bits se produit au 2038-01-19T03: 14: 08 + 0000Z. Mais si vous êtes dans un fuseau horaire UTC -0500 (comme EST en Amérique du Nord), le temps accepté maximum avant le débordement (pour les versions PHP plus anciennes sur Windows) est 2038-01-18T22: 14: 07-0500Z, indépendamment de Que vous le fassiez passer à mktime () ou gmmktime (). "

Answer 4

Je suppose qu'il est stocké dans un nombre fixe de bits, ce qui signifie une limite de l'ampleur de l'horodatage. Nous pourrions faire des calculs pour le comprendre exactement.