Discussion:Bug de l'an 2038
- Admissibilité
- Neutralité
- Droit d'auteur
- Article de qualité
- Bon article
- Lumière sur
- À faire
- Archives
- Commons
Cet article est indexé par le projet Informatique.
Les projets ont pour but d’enrichir le contenu de Wikipédia en aidant à la coordination du travail des contributeurs. Vous pouvez modifier directement cet article ou visiter les pages de projets pour prendre conseil ou consulter la liste des tâches et des objectifs.
| Avancement | Importance | pour le projet | |
|---|---|---|---|
| Bon début | Moyenne |  | Informatique (discussion • critères • liste • stats • hist. • comité • stats vues) |
Cet article ne comporte pas de liste de tâches suggérées. Vous pouvez saisir une liste de tâches à accomplir (par exemple sous forme d'une liste à puces), puis sauvegarder. Vous pouvez aussi consulter la page d'aide.
Texte de l'anecdote publiée :
- Un bug informatique semblable à celui de l’an 2000 pourrait perturber certains ordinateurs le 19 janvier 2038.
Après avoir fait l'objet d'un débat d'admissibilité pour le motif « Je trouve vraiment débile de faire des articles sur des trucs à venir dans + d'une dixaine d'années. Pfff… Non mais ! », cette page a été conservée.
Vous pouvez consulter le débat d'admissibilité à présent clos et archivé.
Le fait qu'une proposition de suppression a déjà été rejetée n'empêche pas de faire une nouvelle proposition pour d'autres motifs. Si vous avez des commentaires, vous pouvez les faire ci-dessous.
En tout cas l'image est fausse : on devrait logiquement passer de 2038 à 1970 et non à 1901.--JojoCrans (d) 1 février 2008 à 00:15 (CET)
- Pas du tout. Si le nombre de seconde est stocké dans une variable de type "entier long" ( de -2 147 483 648 à 2 147 483 647) on passera d'une extrême à l'autre. En représentation décimale, on va donc passer de 2 147 483 648 à -2 147 483 647. Et -2 147 483 648 seconde par rapport au point de repère (en 1970) c'est 1901. CQFD ^^ --Hugo12
Discuter avec moi 11 février 2008 à 20:51 (CET)
3 h 14 m 7 s ou 4 h 14 m 7 s? modifier
C'est plutot 3 h 14 m 7 s et non 4 h 14 m 7 s! Preuve ici: http://www.commentcamarche.net/faq/sujet-8915-le-bug-de-l-annee-2038
Et aussi sur Google, taper "bug de 2038" et ils disent tous 3 h 14 m et 7 s. Idem pour le Wiki anglais. Byrd (d) 27 octobre 2008 à 19:58 (CET)
- Bien d'accord... où as-tu vu un 4h ? Ulrich Von Beck (d) 11 juillet 2009 à 13:27 (CEST)
- Ca a été corrigé depuis un moment...Byrd (d) 16 septembre 2009 à 18:34 (CEST)
le paragraphe sur le passage au 64bit est hors-sujet modifier
Un type int est stocké sur 32bit même sur un système 64bit.--193.52.225.144 (d) 23 juillet 2010 à 18:18 (CEST)
Je vous accorde une chose, c'est que ça n'est pas très bien expliqué. Une autre, c'est que sur un système 64 bits, effectivement un entier est toujours représenté sur 4 octets (sinon on ferait du gaspillage).
Je vous invite à lire la page Time_t ou la page française Horodatage. Vous y apprendrez qu'en C (language), le temps se lit depuis le type "time_t". Et celui-ci peut valoir soit 4 octets (=32 bits), soit 8 octets (=64 bits), soit X bits sur un système X bits.
Et comme il ne faut pas tout prendre pour argent comptant, essayez par vous-même ce code C++ :
#include <iostream>
using namespace std;
int main(int argc, char *argv[])
{
cout << "Un entier signé en C vaut " << sizeof(int) << " octets." << endl;
cout << "Le type time_t est grand de " << sizeof(time_t) << " octets." << endl;
return 0;
}
En 64 bits, le programme affiche :
Un entier signé en C vaut 4 octets.
Le type time_t est grand de 8 octets.
Je laisse votre tag "évasif" car effectivement on n'explique pas pourquoi techniquement, le 64 bits ne subit pas le même problème. Mais faites attention quand vous dites "Hors sujet", ce n'est pas très respecteux pour l'auteur, qui par la même occasion a eu la décence de s'identifier pour apporter sa contribution...--Mathieuclement (d) 12 octobre 2010 à 19:57 (CEST)
- J'ai reformulé la phrase. Il me semble que c'est bon, là ? <Byrd><Discuter !> 13 octobre 2010 à 13:25 (CEST)
Correction dans Linux modifier
Je trouve le lien en référence (vers NextInpact) un peu faible.
Mais on peut retracer d'où vient le problème :
Le titre de ZDNet est affirmatif et trompeur "Le noyau Linux survivra à l’année 2038". D'une part les Linux 64 bits n'ont pas le problème, donc de toute façon ceux-là allaient de toute façon survivre au bug 2038 ! D'autre part la correction n'est pas suffisante en elle-même.
L'article est lui aussi affirmatif.
Linux planet semnle plus proche de la vérité. Il affirme, que le patch du bug n'est pas suffisant en lui-même ! Le titre n'est pas "Linux est prêt" mais "Linux est en train de se préparer", tout est dans la nuance.
Le patch consiste à avoir forcer la structure interne du noyau qui représente le temps à être sur 64 bits.
Mais si votre RTC est matériellement en 32 bits, vous aurez de toute façon un problème.
Il faut ensuite regarder du côté des libc (glibc, µclibc, etc) pour voir s'ils vont proposer une interface à cette structure, puis du côté des applicatifs et des autres langages.