Que devons-nous faire pour nous préparer à 2038 ?

Question

J'aime à penser que certains des logiciels que j'écris aujourd'hui seront utilisés dans 30 ans. Mais je suis également conscient qu'une grande partie de ces logiciels est basée sur la tradition UNIX d'exposer le temps comme le nombre de secondes depuis 1970.

#include <stdio.h>
#include <time.h>
#include <limits.h>

void print(time_t rt) {
    struct tm * t = gmtime(&rt);
    puts(asctime(t));
}

int main() {
    print(0);
    print(time(0));
    print(LONG_MAX);
    print(LONG_MAX+1);
}

L'exécution a pour résultat :

• Thu Jan 1 00:00:00 1970
• Sat Aug 30 18:37:08 2008
• Mar Jan 19 03:14:07 2038
• Fri Dec 13 20:45:52 1901

Les fonctions ctime(), gmtime() et localtime() prennent toutes comme argument une valeur de temps représentant le temps en secondes depuis l'époque (00:00:00 UTC, 1er janvier 1970 ; voir time(3) ).

Je me demande s'il y a quelque chose de proactif à faire dans ce domaine en tant que programmeur, ou devons-nous croire que tous les systèmes logiciels (alias systèmes d'exploitation) seront d'une manière ou d'une autre magiquement mis à jour dans le futur ?

Mise à jour Il semblerait que les systèmes 64 bits soient effectivement à l'abri de ce problème :

import java.util.*;

class TimeTest {
    public static void main(String[] args) {
        print(0);
        print(System.currentTimeMillis());
        print(Long.MAX_VALUE);
        print(Long.MAX_VALUE + 1);
    }

    static void print(long l) {
        System.out.println(new Date(l));
    }
}

• Wed Dec 31 16:00:00 PST 1969
• Sat Aug 30 12:02:40 PDT 2008
• Sat Aug 16 23:12:55 PST 292278994
• Sun Dec 02 08:47:04 PST 292269055

Mais qu'en est-il de l'année 292278994 ?

Answer 1

J'ai écrit un remplacement portable pour time.h (actuellement juste localtime(), gmtime(), mktime() et timegm()) qui utilise le temps 64 bits même sur des machines 32 bits. Il est destiné à être déposé dans les projets C en remplacement de time.h. Il est utilisé en Perl et j'ai l'intention de corriger les problèmes 2038 de Ruby et Python avec lui également. Cela vous donne une marge de sécurité de +/- 292 millions d'années.

Vous pouvez trouver le code au projet y2038 . N'hésitez pas à poser vos questions à la gestionnaire de problèmes .

Pour ce qui est du "ce ne sera pas un problème avant 29 ans", lisez ceci liste des réponses standard à ça. En bref, des choses se passent dans le futur et parfois il faut savoir quand. J'ai aussi une présentation du problème, ce qui n'est pas une solution, et ce qui est .

Oh, et n'oubliez pas que de nombreux systèmes temporels ne gèrent pas les dates antérieures à 1970. Des choses se sont passées avant 1970, parfois vous avez besoin de savoir quand.

Answer 2

Vous pouvez toujours mettre en œuvre RFC 2550 et soyez en sécurité pour toujours ;-)

L'univers connu a un passé et un futur finis. L'âge actuel de l'univers l'univers est estimé dans [Zebu] entre 10 ** 10 et 2 * 10 ** 10 ans. 10 ans. La mort de l'univers est estimée par [Nigel] comme se produisant dans 10 ** 11 - ans et dans [Drake] qu'elle se produira soit dans 10 ** 12 ans pour un univers fermé (le big crunch) ou 10 ** 14 ans pour un univers ouvert (la mort thermique de l'univers). ouvert (la mort thermique de l'univers).

Les programmes conformes à la norme Y10K PEUVENT choisir de limiter la gamme des dates qu'ils qu'ils prennent en charge à celles qui correspondent à la durée de vie prévue de l'univers. Les systèmes compatibles Y10K DOIVENT accepter des dates Y10K allant de 10 ** 12 ans dans le passé à 10 ** 20 ans dans le futur. 12 ans dans le passé à 10 ** 20 ans dans le futur. Les systèmes conformes à la norme Y10K DEVRAI accepter des dates pour au moins 10 ** 29 ans dans le passé et le futur.

Answer 3

Pour quelques réflexions sur la question, voir cette page

Answer 4

Visual Studio est passé à une représentation 64 bits de time_t dans Visual Studio 2005 (tout en laissant _time32_t pour la rétrocompatibilité).

Tant que vous prenez soin de toujours écrire le code en termes de time_t et de ne rien présumer de la taille, alors, comme le souligne sysrqb, le problème sera résolu par votre compilateur.

Answer 5

Je pense que nous devrions laisser le bug en place. Ensuite, vers 2036, nous pourrons commencer à vendre des services de conseil pour de grosses sommes d'argent afin de tout tester. Après tout, n'est-ce pas ainsi que nous avons réussi à gérer le retournement de 1999-2000 ?

Je plaisante !

J'étais assis dans une banque à Londres en 1999 et j'ai été assez étonné de voir un consultant commencer à tester la machine à café pour le passage à l'an 2000. Je pense que si nous avons appris quelque chose de ce fiasco, c'est que la grande majorité des logiciels fonctionneront tout simplement et que la plupart des autres ne provoqueront pas d'effondrement en cas de défaillance et pourront être réparés après coup si nécessaire. En tant que tel, je ne prendrais pas de précautions particulières avant que le moment ne soit venu, à moins que vous n'ayez affaire à un logiciel très critique.