[Caniveau Royal]

1) Ceux qui ont vécu le bug de l'an 2000, le connaissent bien.
Ces années sur deux chiffres qui menaçaient de passer de 1999 à 1900, et qu'il fallait corriger, pour les faire passer en 2000.
Déjà, on va voir comment ça tient en 2030, 2040 et 2050, cette histoire,
parce que dans les vieux programmes, il y pas mal de :

Code:

if anneeSur2chiffres >= 50 (ou 40 ou 30 selon les entreprises et les situations)
  anneeSur4chiffres = 1900 + anneeSur2chiffres
else
  anneeSur4chiffres = 2000 + anneeSur2chiffres

Certains pourraient revenir brutalement au siècle dernier dès 2030...

---

2) Et puis, il y a le bug de l'an 2038
Il est vicieux, il frappe les ordinateurs 32 bits et les vieux programmes qui seront encore présents dans six ans.

Le time en millisecondes, très connu, est calculé depuis la date origine du 01/01/1970.
Un jour de l'année 2038, il va dépasser sa valeur binaire 0111 1111 1111 1111 1111 1111 1111 1111
et passer à 1000 0000 0000 0000 0000 0000 0000 0000,
une valeur négative.

Il faut donc soit changer ces programmes et ces ordinateurs (les vieux ordinateurs ne pourront jamais afficher 18/06/2039)
soit recompiler les vieux programmes en 64 bits, ce qui réclame d'aller vérifier les types de variables partout...

---

3) Et il y a le bug de l'an 2035 (à peu près) qui vient par le réchauffement climatique.

La vitesse de rotation de la terre évolue en conséquence de celui-ci.
Et il imposera non pas d'ajouter une seconde comme on l'a fait aux heures des ordinateurs, à titre exceptionnel, en 2016 au titre d'une resynchronisation avec l'heure astronomique,
mais d'en retrancher une.

-1
Vous vous figurez à quel point les ordinateurs pourront mal accepter ce changement,
alors que les programmes ont toujours considéré le temps comme croissant...

Que faire ?
Arrêter son ordinateur et le faire redémarrer ? Il ne serait pas alors conscient d'avoir été arrêté 47 ou 48 secondes (par exemple), en recevant une heure de démarrage corrigée d'une seconde.

Mais peut-on vraiment arrêter tous les ordinateurs pour les faire se corriger ainsi, si c'est la bonne solution ?
On comprend en tout cas, qu'un certain jour où il sera décidé que cette correction sera appliquée, il ne faudra surtout pas que les ordinateurs en activité
se synchronisent avec une horloge atomique ou un autre système qui leur donne le temps, corrigé de la seconde retranchée, ou alors ils planteront.

[-Interfector-]

Bah en fait vu que c'est trop le bordel a corriger dans les systemes info, ils vont tout simplement supprimer ces secondes intercalaires. Ils feront des corrections seulement au dela d'un delta trop important (on a ajouté 27 seconde depuis 1972).
4eme resolution prise en 2022, les modalités seront effectivement fixées en 2026 pour que ca se passe au mieux et pour tout le monde :
https://www.bipm.org/fr/cgpm-2022

C'est donc un non probleme, comme pour le "bug" de l'an 2000 qui n'a jamais eu lieu. On en parle comme si c'etait irrémédiable et une fatalité avec un nom en consequence. Dans les faits, il n'y a pas eu de bug de l'an 2000 puisqu'on savait ce qui allait arriver et qu'on a prevenu la chose.

[Caniveau Royal]

Citation :

Publié par -Interfector-

Bah en fait vu que c'est trop le bordel a corriger dans les systemes info, ils vont tout simplement supprimer ces secondes intercalaires.

C'est l'inverse : il n'y a pas de secondes intercalaires. On ne passe pas de 14'' à 16'' sans passer par 15.
C'est le contraire → On rejoue une seconde qui a déjà existé.
Ou, pour dire autrement : on a une seconde qui dure deux secondes : 14'', 15'', 15, 16''

Citation :

Publié par -Interfector-

C'est donc un nom probleme, comme pour le "bug" de l'an 2000 qui n'a jamais eu lieu. On en parle comme si c'etait irrémédiable et une fatalité avec un nom en consequence. Dans les faits, il n'y a pas eu de bug de l'an 2000 puisqu'on savait ce qui allait arriver et qu'on a prevenu la chose.

Il a bien eu lieu, et des systèmes ont sauté.
Mais effectivement la chose a été prévenue, au prix d'un énorme travail de trois ou quatre années,
dont les deux dernières où toutes les entreprises qui avaient des moyens et gros systèmes (AS/400, IBM 36 ou 38, MVS...)
ne faisaient quasiment que ça en développement logiciel (avec le début du passage à l'Euro, aussi).

Ça, ou migrer leurs développements en Java sur PC.
Java a connu un essor fulgurant alors parce qu'il était gratuit et arrivait à point nommé
pour des entreprises qui devaient tout re-coder le vieux Cobol dans un autre langage, ailleurs.

[Dr. Troy]

Citation :

Publié par Caniveau Royal

Il a bien eu lieu, et des systèmes ont sauté.

En vulgarisant, un ordinateur ne compte pas en secondes depuis une date x ? L'affichage type YY/MM/DD c'est juste "pour nous" non ?

[Caniveau Royal]

Citation :

Publié par Dr. Troy

En vulgarisant, un ordinateur ne compte pas en secondes depuis une date x ? L'affichage type YY/MM/DD c'est juste "pour nous" non ?

Oui, c'est bien ça.
Et je dirais que ça irait si on disait : on répète la seconde 15 d'un jour, heure, minute, seconde donnée,
si l'unité de temps d'un ordinateur était la seconde...

Mais ce que l'on fait, c'est que l'on rejoue de la
155678712245578194763^ème milliseconde depuis 1970 à la 155678712245578195762^ème,
et même pour l'ordinateur, bien en deçà de ça :

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-18-amd64 ro quiet
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
[ 0.000376] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved[ 0.000384] last_pfn = 0x103f300 max_arch_pfn = 0x400000000
[ 0.004022] ACPI: SSDT 0x00000000BCA82000 008C98 (v02 AMD AmdTable 00000002 MSFT 04000000)
[ 0.004048] ACPI: Reserving SSDT table memory at [mem 0xbca7e000-0xbca81c99]
[ 0.004261] DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
[ 0.011039] printk: log_buf_len individual max cpu contribution: 4096 bytes
[ 0.041781] ftrace: allocating 40188 entries in 157 pages
[ 0.048111] ftrace: allocated 157 pages with 5 groups
[ 0.050796] rcu: srcu_init: Setting srcu_struct sizes based on contention.[ 0.371188] Switched APIC routing to physical flat.
[ 0.371811] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.390980] Calibrating delay loop (skipped), value calculated using timer frequency.. 6787.40 BogoMIPS (lpj=13574804)
[ 0.007002] hpet0: 3 comparators, 32-bit 14.318180 MHz counterfffff]
[ 0.016384] pci_bus 0000:06: resource 2 [mem 0xd0000000-0xe1ffffff 64bit pref]
[ 0.026385] pci_bus 0000:08: resource 1 [mem 0xfc600000-0xfc8fffff]
[ 0.036509] pci 0000:06:00.1: extending delay after power-on from D3hot to 20 msec

Les ordinateurs ne vont pas apprécier du tout de passer de 0.390980 à 0.007002...
Beaucoup de composants risquent de coincer.

---

Et si tu éteins un ordinateur pour qu'il se "corrige" et reparte avec une bonne heure,
il va se connecter à des ordinateurs qui, eux, n'auront pas encore été corrigés.
Parce qu'il n'est pas possible, sans doute, de tous les corriger en même temps

à [ 0.048111] mon ordinateur corrigé envoie un message demandant de faire quelque-chose
à un ordinateur non corrigé qui a lui-même un message daté à [ 0.050796] lui demandant de faire un peu différemment.

l'ordinateur non corrigé dit : "Mon message a la préséance, parce que 0.050796 > 0.048111 : j'ai le plus récent.
Ce n'est pas vrai ! En temps physiquement vécu, celui de l'ordinateur corrigé est en fait à 1.048111, et 1.048111 > 0.050796 !

---

@-Interfector- ci-dessous : il n'y a pas de secondes intercalaires dans notre cas de figure. Comment intercalerais-tu des secondes alors que tu en supprimes ?

[-Interfector-]

Citation :

Publié par Caniveau Royal

C'est l'inverse : il n'y a pas de secondes intercalaires.

Nan mais en fait c'est leur dénomination par les instances internationales (Bureau Central du Service international de la rotation terrestre et des systèmes de référence basé à Paris) qui s'occupent de gerer le temps dont bon... je veux bien que tu remettes tout ca en question mais ca va etre tendu pour toi...
Toi tu parles encore de ta seconde qui doit etre soustraite, sauf que c'est jamais arrivé donc tu peux pas dire "nan mais en vrai c'est comme ca", c'est jamais arrivé et ils veulent faire en sorte que ca n'arrive pas.
Et jusqu'a maintenant, quand on ajoutait une seconde, on faisait pas 14/15/15/16, là on a perdu une seconde...

[SekYo]

Citation :

Publié par Dr. Troy

En vulgarisant, un ordinateur ne compte pas en secondes depuis une date x ? L'affichage type YY/MM/DD c'est juste "pour nous" non ?

C'est un peu plus compliqué que ça.
Dans tous les cas, tout ce qui sort d'un ordinateur c'est des nombres... avec derrière une certaine convention pour les interpréter (comme ANSII ou UTF-8 pour ce texte par exemple).

Ce que décrit Caniveau Royal c'est ce qu'on appelle un "timestamp" et c'est en effet l'un des moyens les plus utilisés (notamment dans les anciens systèmes) pour stocker des dates. Mais au final ce n'est qu'une "interprétation" d'un nombre. On a décidé qu'on partait d'un point de référence arbitraire, le 1er janvier 70, et qu'on comptait depuis le nombre de secondes (ou de millisecondes dans certains cas d'ailleurs). Et après comme 1711716186 c'est un peu chiant à interpréter pour un humain, bin y a des petits bouts de programmes qui transforment ça en texte lisible par nous (29 mars 2024 8h45 ici).

Mais la plupart des systèmes ou langages ont aussi maintenant des types dates "natifs", qui ne reposent absolument pas sur la référence du 1er janvier 1970. Ils ont chacun leurs avantages ou inconvénients; par exemple souvent en terme de stockage ils prennent plus de places qu'un simple timestamp 32 ou 64 bits. Sur la base de donnée PostgreSQL par exemple, tu as un type pour stocker date + heure + fuseau horaire sur 8 octets: https://www.postgresql.org/docs/curr...-datetime.html
Ces types "non timestamp" ne sont pas du tout affectés par le problème décrit par Caniveau (qui est réel, même si je pense qu'il over-psychote le truc).

[Dr. Troy]

Citation :

Publié par Caniveau Royal

Oui, c'est bien ça.

Citation :

Publié par SekYo

C'est un peu plus compliqué que ça.
Dans tous les cas, tout ce qui sort d'un ordinateur c'est des nombres... avec derrière une certaine convention pour les interpréter (comme ANSII ou UTF-8 pour ce texte par exemple).

Oui je sais bien, pour ça que je disais en vulgarisant (j'utilise des timestamps en secondes pour mes scripts bash par exemple).
À la base j'ai quoté le fait que des systèmes aient plantés avec le bug de l'an 2000. On parle de quels systèmes qui confondraient 1900 avec 2000 alors qu'un ordinateur ne conçoit pas la date comme ça ? C'était mon interrogation. Je me suis jamais penché sur la question mais pour moi c'était un truc bidon cette histoire de bug de l'an 2000, comme dit plus haut.

[-Interfector-]

Citation :

Publié par Caniveau Royal

@-Interfector- ci-dessous : il n'y a pas de secondes intercalaires dans notre cas de figure. Comment intercalerais-tu des secondes alors que tu en supprimes ?

En mettant un signe moins devant ta seconde intercalaire, mais comme les systemes ont jamais ete prevu pour ca, on le fera pas. Les secondes intercalaires c'est le nom pour designer les secondes d'ajustement, le truc a ete uniquement prevu pour ajouter des secondes donc ca s'appelle comme ca puisque ca ne servait qu'a ajouter 1 seconde. Puis ils se sont rendu compte qu'il faudrai en retirer une, ils arretent leur systeme de seconde intercalaire. Il n'y a donc pas lieu de denommer une seconde qu'on retire puisqu'ils le feront pas. Reste les secondes intercalaires qui elles ont existés et existeront encore sous la meme forme jusqu'en 2035 puis sous une autre apres (au lieu d'ajuster a la seconde, on ajustera a 10-30-60 secondes sur des temps plus long qui permettront d'anticiper si soucis il y a).

[SekYo]

Citation :

Publié par Dr. Troy

Oui je sais bien, pour ça que je disais en vulgarisant (j'utilise des timestamps en secondes pour mes scripts bash par exemple).
À la base j'ai quoté le fait que des systèmes aient plantés avec le bug de l'an 2000. On parle de quels systèmes qui confondraient 1900 avec 2000 alors qu'un ordinateur ne conçoit pas la date comme ça ? C'était mon interrogation. Je me suis jamais penché sur la question mais pour moi c'était un truc bidon cette histoire de bug de l'an 2000, comme dit plus haut.

Hypothèse de ma part (j'étais trop jeune pour bosser à cette époque), mais toutes les dates n'étaient pas stockées sous forme de timestamp/format natif en interne. Si ton seul besoin de stockage c'est pour l'afficher après (par exemple pour un formulaire administratif), c'était sans doute plus simple à l'époque de stocker directement la date au format "texte" avec l'année sur deux chiffres. Ca permet de la ré-utiliser directement, là ou avec un timestamp ou un autre format, bin faut faire des conversions coûteuses pour les transformer en truc affichable.

On à un peu tendance à l'oublier aujourd’hui avec l'omniprésence de l'informatique et la puissance de nos ordinateurs, mais la combinaison y a 50 ans de :
- la puissance et stockage disponible sont beaucoup plus limités, donc faut trouver le meilleur compromis entre taille et cout de traitement...
- l'informatique était moins omniprésente et vitale, du coup les conséquences pour dans 40 ans (bon ce point long terme a pas énormément changé sauf exception )...

Font que c'est pas si surprenant qu'initialement des devs aient choisis de stocker "1967" sous la forme "67", puis les programmes se complexifiant, on a a commencé à faire des calculs/traitements sur ces dates, mais sans revoir leur représentation/stockage interne (parce que pas le temps, trop compliqué/coûteux, toussa pour un truc qui se passera dans 30 ans...) etc... Ce qui conduit à la situation du bug de l'an 2000.

[Bjorn]

Citation :

Publié par Caniveau Royal

1) Ceux qui ont vécu le bug de l'an 2000, le connaissent bien.

Oui on le connaît bien.
Et on sait donc que si, comme le passage à l'euro, ou plein d'autres changements techniques non prévus, cela a demandé du boulot à pas mal d'informaticiens, ca n'a absolument pas été, même de très loin, le cataclysme annonce par beaucoup.

Tu remontes des points sur des sujets bien plus triviaux. Ça ne présente aucun risque majeur et n'aura d'impact sur personne, à part ceux qui bosseront dessus, ca leur fera leur paie.

[-Interfector-]

A propos, le probleme de date stockée en 32b n'arrivera pas en 2031 mais en 2038
https://www.wikiwand.com/fr/Bug_de_l'an_2038
Et autre precision, ca ne fera pas revenir a 0 (1970) parce qu'une incrementation de la 2 147 483 647eme seconde, ca donne la -2 147 483 647eme seconde entier sur 32b signé), soit 1901 (une minorité de systeme representent ses dates par un entier non signé, ce qui provoquerait pour eux le probleme en 2106 et non 2038).

[Caniveau Royal]

Citation :

Publié par SekYo

c'était sans doute plus simple à l'époque de stocker directement la date au format "texte" avec l'année sur deux chiffres. Ca permet de la ré-utiliser directement, là ou avec un timestamp ou un autre format, bin faut faire des conversions coûteuses pour les transformer en truc affichable.

En Cobol, une année était souvent déclarée ainsi (de mémoire) :
ANNEE PIC 99.
Où 9 signifie un chiffre. (taille d'un octet, au format EBCDIC, souvent, avec IBM).

Le langage Cobol ne savait pas, à l'époque, gérer une date par lui-même. Je ne sais pas si ça a changé.

(Par ailleurs, IBM voulant vendre du disque et de la mémoire, il optimisait rarement la place...
il a commencé à prendre en compte le VARCHAR des bases de données en 1995.
Pas avant. Avant tu faisais PRENOM CHAR(50) et si tu t'appelais René, c'était le même tarif : 50 octets dépensés)

---

Citation :

Publié par Bjorn

Oui on le connaît bien.

Et on sait donc que si, comme le passage à l'euro, ou plein d'autres changements techniques non prévus, cela a demandé du boulot à pas mal d'informaticiens, ca n'a absolument pas été, même de très loin, le cataclysme annonce par beaucoup.

Il n'a pas été un cataclysme, au prix d'un énorme et très coûteux travail.
Et aussi, parce que les ordinateurs dont les logiciels n'ont pas survécu, et qui n'ont pas été changés, n'étaient pas critiques.
En l'an 2000, la planète était déjà bien informatisée, mais aujourd'hui c'est autrement plus.

La correction par la seconde négative aura l'atout qu'on pourra choisir son moment d'application.
Et à mon avis, ce sera surtout une affaire de mise à jour de systèmes d'exploitation.

[Bardiel Wyld]

Citation :

Publié par Caniveau Royal

Il n'a pas été un cataclysme, au prix d'un énorme et très coûteux travail.

Mdr, très honnêtement "très coûteux" surtout parce que ça a été survendu entre autres par les ESN (je le sais pour y avoir participé ).
Selon les boîtes il n'y avait pas forcément tant de travail que ça, par contre ça a bien fait prospérer les prestas mdr

[Caniveau Royal]

Citation :

Publié par Bardiel Wyld

Mdr, très honnêtement "très coûteux" surtout parce que ça a été survendu entre autres par les ESN (je le sais pour y avoir participé ).
Selon les boîtes il n'y avait pas forcément tant de travail que ça, par contre ça a bien fait prospérer les prestas mdr

J'ai fait que ça pendant trois ans, et c'était très très volumineux, ce qu'il y avait à accomplir.
Ça a surtout touché le monde de l'informatique de gestion, cela dit.

Je suis d'accord : l'enrichissement des Cap Gemini et autres, date de ce moment.

[Aloïsius]

Cela faisait longtemps qu'on ne nous avait pas menacé du bug de la mort.


Cela étant, si les formats de date pouvaient enfin évoluer pour aller librement de -10 000 av JC jusqu'à + 10 000, ce serait bieng. Parce que ce genre de truc :


C'est gavant. Les gens qui ont fait excel sont certain que l'univers a commencé le 1e Janvier 1900, avant, le temps, l'espace et l'univers n'existent pas et disparaissent dans une singularité cosmique incompréhensible.

[Metalovichinkov]

Citation :

Publié par Bardiel Wyld

Mdr, très honnêtement "très coûteux" surtout parce que ça a été survendu entre autres par les ESN (je le sais pour y avoir participé ).
Selon les boîtes il n'y avait pas forcément tant de travail que ça, par contre ça a bien fait prospérer les prestas mdr

Ouais c'est surtout ça que j'ai entendu : des primes exceptionnelles débilement hautes adossées à des avenants pour ne pas chercher ailleurs sur la période 2000-2001. Et quand je dis débilement haute c'était genre 10% du salaire versé sur les 4 dernières années, grosso modo 5 mois de salaires
Mais les gens en poste à l'époque m'ont tous dit qu'il s'est absolument rien passé alors que je bossais essentiellement sur MVS, pas vraiment le truc le plus à la pointe sur ce genre d'infos.

D'ailleurs j'ai du mal à voir ce qui poserait problème avec la seconde intercalaire, c'est différent du changement d'heure? Chaque année au changement d'heure, on a des traitements qui finissent avant qu'ils commencent (démarré à 2h58, fini à 2h03 et tout va bien)

Citation :

Publié par Caniveau Royal

(Par ailleurs, IBM voulant vendre du disque et de la mémoire, il optimisait rarement la place...
il a commencé à prendre en compte le VARCHAR des bases de données en 1995.
Pas avant. Avant tu faisais PRENOM CHAR(50) et si tu t'appelais René, c'était le même tarif : 50 octets dépensés)

Les formats fixes sont encore vachement utilisés ici, ça permet d'avoir des enregistrements d'une taille unique. Quand tu as quelques millions d'enregistrements ça fait pas une grosse diff, mais quand tu dois en traiter quelques dizaines de millions, bah ça revient moins cher d'avoir plus de stockage que plus de CPU pour le même temps de calcul, puis ça te permet de faire des allocations au poil de cul près.
En tout cas c'est ce que m'avait expliqué nos DBA sur DB2

[-Interfector-]

Citation :

Publié par Metalovichinkov

D'ailleurs j'ai du mal à voir ce qui poserait problème avec la seconde intercalaire, c'est différent du changement d'heure? Chaque année au changement d'heure, on a des traitements qui finissent avant qu'ils commencent (démarré à 2h58, fini à 2h03 et tout va bien)

De ce que je comprend, c'est qu'il n'y a aucune norme pour ces secondes intercalaires, ca fonctionnait aujourd'hui pour ajouter une seconde, mais ils preferent pas prendre de risque pour une grande premiere : en retirer une. Et c'est l'occasion pour eux de regler cette absence de norme. Leur solution est donc de supprimer ces secondes intercalaires, plutot que de prendre le risque de chacun continue a faire a sa sauce et surtout avec le risque que chacun se detache de la norme temps UTC.

Ya plus de detail dans le premier lien que j'avais fourni :

Citation :

• les opérateurs de réseaux numériques et systèmes GNSS ont développé et appliqué différentes méthodes d’introduction des secondes intercalaires qui ne suivent pas de normes convenues,
• la mise en œuvre de ces différentes méthodes non coordonnées menace la résilience des capacités de synchronisation qui étayent des infrastructures nationales critiques,
• l’utilisation de ces différentes méthodes génère par ailleurs de la confusion, ce qui compromet la reconnaissance de l’UTC comme unique échelle de temps de référence et remet en question le rôle des laboratoires nationaux de métrologie (et laboratoires désignés) comme sources de traçabilité aux étalons métrologiques nationaux et internationaux,
• les récentes observations de la vitesse de la rotation de la Terre indiquent qu’il pourrait être nécessaire d’introduire pour la première fois une seconde intercalaire négative, ce qui n’a jamais été envisagé ou testé,
• le Comité consultatif du temps et des fréquences (CCTF) a conduit une étude approfondie auprès d’institutions métrologiques, scientifiques et technologiques, ainsi qu’auprès d’autres parties prenantes, dont les réponses confirment la position selon laquelle des mesures doivent être prises afin de résoudre la question des discontinuités de l’UTC,