Que faire pour préparer 2038 ?

Question

J'aimerais 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 cela est basée sur la tradition UNIX d'exposer le temps en 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 aboutit à :

• jeu. 1er janvier 00:00:00 1970
• Samedi 30 août 2008 18:37:08
• mar. 19 janvier 03:14:07 2038
• Vendredi 13 décembre 20:45:52 1901

Les fonctions ctime(), gmtime() et localtime() prennent toutes comme argument une valeur temporelle 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 mis à niveau comme par magie à l'avenir ?

Mise à jour Il semblerait qu'en effet les systèmes 64 bits soient à l'abri de cela :

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));
    }
}

• Mercredi 31 décembre 16:00:00 PST 1969
• Samedi 30 août 2008 12:02:40 PDT
• Samedi 16 août 23:12:55 PST 292278994
• Dim. 02 décembre 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 une heure 64 bits même sur des machines 32 bits.Il est destiné à être intégré aux projets C en remplacement de time.h.Il est utilisé en Perl et j'ai l'intention de résoudre également les problèmes 2038 de Ruby et Python.Cela vous donne une plage de sécurité de +/- 292 millions d'années.

Vous pouvez trouver le code au projet y2038.N'hésitez pas à poser vos questions au Traqueur d'incidents.

Quant au "cela ne sera pas un problème avant 29 ans", parcourez ceci liste de réponses standards pour que.Bref, des choses arrivent dans le futur et il faut parfois savoir quand.j'ai aussi une présentation sur le problème, ce qui n'est pas une solution et ce qui l'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, il faut parfois savoir quand.

Answer 2

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

L'univers connu a un passé et un avenir finis.L'âge actuel de l'univers est estimé dans [Zebu] entre 10 ** 10 et 2 * 10 ** 10 ans.La mort de l'univers est estimée à [Nigel] pour se produire en 10 ** 11 ans et dans [Drake] comme se produisant soit dans 10 ** 12 ans pour un univers fermé (le grand croquant) ou 10 ** 14 ans pendant un univers ouvert (la mort thermique de l'univers).

 

Les programmes conformes à Y10K peuvent choisir de limiter la gamme des dates qu'ils soutiennent à ceux conformes à la durée de vie prévue de l'univers.Les systèmes conformes à Y10K doivent accepter les dates de Y10k de 10 ** 12 ans au cours de 10 ** 20 ans dans le futur.Les systèmes conformes à Y10K devraient accepter les dates pendant au moins 10 ** 29 ans dans le passé et l'avenir.

Answer 3

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

Tant que vous faites attention à toujours écrire du code en termes de time_t et que vous ne présumez rien de la taille, comme le souligne sysrqb, le problème sera résolu par votre compilateur.

Answer 4

Je pense que nous devrions laisser le bug dedans.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 refinancement de 1999-2000.

Je rigole, c'est tout!

J'étais assis dans une banque à Londres en 1999 et j'ai été très étonné lorsque j'ai vu un consultant commencer à tester la machine à café Y2K.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 de fusion en cas de panne et pourront être réparés après l'événement si nécessaire.En tant que tel, je ne prendrais aucune précaution particulière avant beaucoup plus près.

Answer 5

Compte tenu de mon âge, je pense que je devrais contribuer beaucoup à ma retraite et payer tous mes dettes, donc il faudra que quelqu'un d'autre installe le logiciel !

Désolé, si vous pensez à la « valeur actuelle nette » de tout logiciel que vous écrivez aujourd’hui, cela n’a aucun effet sur ce que fera le logiciel en 2038.Un « retour sur investissement » de plus de quelques années est rare pour tout projet logiciel, vous gagnez donc beaucoup plus d'argent pour votre employeur en expédiant le logiciel plus rapidement, plutôt que de penser aussi loin.

La seule exception courante concerne les logiciels qui doivent prédire l'avenir, 2038 étant déjà un problème pour les systèmes de cotation hypothécaire.

Answer 6

Conservez une bonne documentation et incluez une description de vos dépendances temporelles.Je ne pense pas que beaucoup de gens aient pensé à la difficulté de cette transition, par exemple les cookies HTTP vont être rompus à cette date.

Answer 7

Que faire pour préparer 2038 ?

Cachez-vous, car l’apocalypse arrive.

Mais sérieusement, j'espère que les compilateurs (ou les personnes qui les écrivent, pour être précis) pourront gérer cela.Ils ont presque 30 ans.J'espère que c'est assez de temps.

À quel moment commençons-nous à préparer l’an 10K ?Des fabricants de matériel informatique/laboratoires de recherche ont-ils étudié le moyen le plus simple de passer à la nouvelle technologie dont nous aurons besoin à cause de cela ?

Answer 8

Je travaille en embarqué et j'ai pensé publier notre solution ici.Nos systèmes sont sur 32 bits, et ce que nous vendons actuellement a une garantie de 30 ans, ce qui signifie qu'ils rencontreront le bug de l'année 2038.Une mise à niveau à l'avenir n'était pas une solution.

Pour résoudre ce problème, nous avons fixé la date du noyau 28 ans plus tôt que la date actuelle.Ce n'est pas un décalage aléatoire, 28 ans, c'est exactement le temps qu'il faudra pour que les jours de la semaine correspondent à nouveau.Par exemple, j'écris ceci un jeudi et la prochaine fois que le 7 mars sera un jeudi, c'est dans 28 ans.

De plus, toutes les applications qui interagissent avec les dates sur nos systèmes prendront la date système (time_t), la convertiront en une heure64_t personnalisée et appliqueront le décalage de 28 ans à la bonne date.

Nous avons créé une bibliothèque personnalisée pour gérer cela.Le code que nous utilisons est basé sur ceci : https://github.com/android/platform_bionic

Ainsi, avec cette solution, vous pouvez facilement vous acheter 28 ans supplémentaires.

Answer 9

D'ici 2038, les bibliothèques de temps devraient toutes utiliser des entiers de 64 bits, ce ne sera donc pas si grave (sur des logiciels qui ne sont pas complètement maintenus).

Les programmes COBOL peuvent cependant être amusants.

Answer 10

Le mot clé étant "devrait".

Si vous avez besoin d'assurer la pérennité, vous pouvez créer votre propre classe date/heure et l'utiliser, mais je ne le ferais que si vous pensez que ce que vous écrivez sera utilisé sur un système d'exploitation existant.