#1 Le 22/03/2017, à 10:41
- CM63
La routine mktime() plante en 32bits pour annee>2038?
Bonjour,
Il paraîtrait que la fonction mktime() en 32bits planterait pour des années supérieures à 2038? C'est vrai ou pas? Si c'est vrai, il faudrait peut-être s'en préoccuper car en 2038 il y aura encore beaucoup de machine en 32bits. Et de toutes façons ça planterait déjà pour des calculs de date dans le futur (planification, agenda).
Quoi? Quelque chose que je ne connais pas et qui me fait l'affront d'exister?!
Hors ligne
#2 Le 22/03/2017, à 12:26
- soshy
Re : La routine mktime() plante en 32bits pour annee>2038?
Salut,
Il paraîtrait que la fonction mktime() en 32bits planterait pour des années supérieures à 2038? C'est vrai ou pas?
Oui, ainsi que d'autres fonctions dans le meme genre.
Si ca peut te rassurer, plein de gens tres intelligents s'en occupent et reflechissent deja depuis un certain temps a la question. Un exemple ici.
2038 il y aura encore beaucoup de machine en 32bits.
Ca m'etonnerai... 2038 c'est dans 21 ans.
- Si on regarde 20 ans en arriere on avait quoi comme machine ? Le top c'etait des pentium II 300Mhz (sorti en mai 1997). Tu connais beaucoup de gens qui utilisent encore un pentium II ? Il est ou l'interet ? Aujourd'hui tu peux avoir un raspberry qui coute rien, qui est 10 fois plus performant et consomme 100 fois moins d'energie a l'utilisation.
- Ca fait deja plus de 10 ans que le 64bit est la norme pour n'importe quelle machine (a part certaines saloperies du genre atom).
- Le support du 32bit est deja en train de disparaitre. Chrome 32bit (sur Linux, le reste je sais pas) n'existe plus, ubuntu parlait il y a pas si longtemps d'arreter de fournir des versions 32bit d'ici 2 ou 3 ans, etc.
Hors ligne
#3 Le 22/03/2017, à 12:37
- CM63
Re : La routine mktime() plante en 32bits pour annee>2038?
Si ca peut te rassurer, plein de gens tres intelligents s'en occupent
Ca me rassure, en effet, c'était un peu l'objet de ma question.
CM63 a écrit :2038 il y aura encore beaucoup de machine en 32bits.
Ca m'etonnerai... 2038 c'est dans 21 ans.
Certes, mais on peut s'inquiéter pour les systèmes actuels qui font de la prospective pour dans 21ans (agendas, logiciels de planning, etc)
Dernière modification par CM63 (Le 22/03/2017, à 12:39)
Quoi? Quelque chose que je ne connais pas et qui me fait l'affront d'exister?!
Hors ligne
#4 Le 22/03/2017, à 13:21
- soshy
Re : La routine mktime() plante en 32bits pour annee>2038?
A titre personnel j'ai du mal a me voir prendre un rendez-vous pour dans 21 ans 
Sinon, soit les developpeurs ont ete intelligent et ont contourne le probleme parce que leur logiciel etait prevu pour gerer des trucs loins dans l'avenir, soit une mise a jour des dit logiciels (pour peu qu'ils ne soient pas abandonnes) arrivera avec probablement un passage en 64 bit obligatoire.
On a survecu a l'an 2000, j'ai pas souvenir que ca ait ete l'apocalypse d'un point de vu end-user, je pense qu'on survivra a 2038 
.
Dernière modification par soshy (Le 22/03/2017, à 13:23)
Hors ligne
#5 Le 22/03/2017, à 13:26
- MicP
Re : La routine mktime() plante en 32bits pour annee>2038?
…On a survecu a l'an 2000, j'ai pas souvenir que ca ait ete l'apocalypse d'un point de vu end-user,…
Par contre, ça a rapporté pas mal d'argent à certains cette affaire.
J'avais bien aimé ce que les guignols de l'info avaient fait à ce sujet
=======
Ce n'est pas parce qu'un microprocesseur utilise des registres de 32 bits (ou moins) qu'il ne peut pas faire de calcul de date sur xxxxxxxxxxxxx bits
et il n'en sera d'ailleurs pas plus performant : Voir : processeurs RISC
Une amie me disait :
La différence entre un petit sac à main et un plus gros, c'est que pour le deuxième,
on passe plus de temps à se rendre compte qu'on a oublié son rouge à "lièvre"
=======
root@debg53sw:~# date -d '+100000000000000000 year'
samedi 22 mars 1569327073, 13:10:31 (UTC+0100)
root@debg53sw:~# Dernière modification par MicP (Le 22/03/2017, à 14:19)
Hors ligne
#6 Le 22/03/2017, à 13:41
- soshy
Re : La routine mktime() plante en 32bits pour annee>2038?
Je suis trop jeune pour avoir vecu le bug de l'an 2000 d'un point de vue de developpeur (j'aurai bien aime voir ce que ca impactait vraiment a part l'affichage et les logiciels mal codes), mais c'est vrai que la video des gignols semble assez juste d'un point de vue exterieur 
Ah, les gignols, ils me manquent...
Hors ligne
#7 Le 22/03/2017, à 13:44
- JLK
Re : La routine mktime() plante en 32bits pour annee>2038?
A titre personnel j'ai du mal a me voir prendre un rendez-vous pour dans 21 ans
Tu n'as pas pris de rendez-vous en 2038 ? L'année de la victoire absolue de GNU/Linux et des logiciels libres ?
Pfff... Pessimiste ! 
Dernière modification par JLK (Le 22/03/2017, à 13:48)
Hors ligne
#8 Le 22/03/2017, à 14:25
- MicP
Re : La routine mktime() plante en 32bits pour annee>2038?
Entre temps, en 2012, on a aussi eu droit à ça
Hors ligne
#9 Le 22/03/2017, à 15:58
- CM63
Re : La routine mktime() plante en 32bits pour annee>2038?
A titre personnel j'ai du mal a me voir prendre un rendez-vous pour dans 21 ans
Non mais par contre un emprunt bancaire qui se termine dans 21ans ça n'a rien d'utopique. Et quand on voit qu'il y a quelques années on a "découvert" que les distributeurs de billets tournaient encore sous un Windows XP plus maintenu et plus sécurisé, ça ne me rassure pas.
Il faudrait s'en occuper justement pour éviter d'être la proie des magouilles commerciales telles que celles qui ont eu lieu en 2000.
Sans parler d'apocalypse, je peux vous dire qu'en 2000, j'ai passé beaucoup de temps à corriger les erreurs, à revenir en arrière par rapport aux "corrections automatiques des dates" qui n'avaient pas lieu d'être faites, car la date était déjà été corrigée auparavant par un autre logiciel, et j'en passe. Et ce, plusieurs années après l'an 2000.
Les principales erreurs survenaient dans les codes calculés à partir des dates, et non dans les dates elles-mêmes.
C'est ce genre de conneries que je crains, plutôt que l'apocalypse.
Quoi? Quelque chose que je ne connais pas et qui me fait l'affront d'exister?!
Hors ligne