Le Bureau international des poids et mesures est chargé de coordonner le système international d'unités. Depuis la définition du mètre comme étant la longueur du trajet parcouru dans le vide par la lumière pendant une durée de 1/299 792 458 de seconde, toutes les unités sont définies par des phénomènes physiques reproductibles.
La conférence du BIPM était réunie la semaine dernière, et a pris plusieurs résolutions qui vont affecter les applications technologiques.
Nouveaux préfixes du SI
Les nombres manipulés en sciences et technologies sont de plus en plus importants, aussi pour prendre en compte ces nouveaux besoins de nouveaux préfixes multiplicateurs d'unités ont été définis :
| Facteur | Préfixe | Symbole |
|---|---|---|
| 1027 | ronna | R |
| 10-27 | ronto | r |
| 1030 | quetta | Q |
| 10-30 | quecto | q |
Ces préfixes sont donc ajoutés à :
| Facteur | Préfixe | Symbole |
|---|---|---|
| 1024 | yotta | Y |
| 1021 | zetta | Z |
| 1018 | exa | E |
| 1015 | péta | P |
| 1012 | téra | T |
| 109 | giga | G |
| 106 | méga | M |
| 103 | kilo | k |
| 102 | hecto | h |
| 101 | déca | da |
| 10–1 | déci | d |
| 10–2 | centi | c |
| 10–3 | milli | m |
| 10–6 | micro | µ |
| 10–9 | nano | n |
| 10–12 | pico | p |
| 10–15 | femto | f |
| 10–18 | atto | a |
| 10–21 | zepto | z |
| 10–24 | yocto | y |
Fin de la seconde intercalaire ?
Le temps universel coordonné, appelé UTC, est établi par le BIPM en considérant qu'une seconde correspond à la durée de 9 192 631 770 oscillations de la fréquence de transition hyperfine de l'atome de césium. De son côté, le service international de la rotation terrestre et des systèmes de référence établit le temps astronomique, appelé UT1, avec une seconde définie comme 1/86400ème d'une rotation complète (jour). Le temps UT1 est physiquement instable, la rotation de la planète ayant tendance à décéreler depuis la mise en place du temps universel.
Aussi, lorsque UT1 est décalé de plus de 0,9 secondes de UTC, le temps UTC est modifié pour prendre en compte le décalage (au 30 juin ou 31 décembre, la seconde 23:59:60 est ajoutée entre 23:59:59 et 00:00:00). Cette modification est censée être prise en compte par les systèmes, mais cela ne se fait pas toujours sans bug (23:59:60 n'est pas toujours bien géré par les logiciels, tout comme les jours de 86401 secondes). Pire, la rotation est actuellement en train d’accélérer, et rien n'a été prévu pour supprimer une seconde à UTC.
La décision a donc été prise de compter sur une prévision des variations astronomiques des 100 prochaines années pour définir les décalages à venir entre UTC et UT1, puis on fixera alors une heure UTC stable qui minimisera le décalage de celui-ci pendant ce siècle. Cette modification devra être réalisée d'ici 2035. Pour le moment on ignore l'ordre de grandeur de ce décalage et comment celui-ci sera implémenté (si la valeur doit être augmentée on passera a priori par des ajouts de secondes intercalaires quelques années de suite).
Aller plus loin
- Lite des résolutions 2022 (59 clics)
- Préfixes du SI (62 clics)
- Bureau international des poids et mesures (45 clics)
- International Earth rotation and reference systems service (34 clics)
# On joue à qui a la plus grosse ?
Posté par Denis Dordoigne . Évalué à 5. Dernière modification le 25 novembre 2022 à 10:28.
Le plus gros préfixe que j'ai eu à manipuler est le zetta, avec une partition de 64 Zo (ou ZiO ? le df n'affiche que 64Z, je ne me souviens jamais de l'unité) :
Après un fsck on est retombé à 4 To, c'était très décevant. Sinon je n'ai jamais eu à manipuler plus d'une dizaine de Po.
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: On joue à qui a la plus grosse ?
Posté par alkino . Évalué à 3.
Je travaille sur un gros PC toute la journée :
```
Filesystem Size Used Avail Use% Mounted on
data 6.2P 4.3P 2.0P 69%
# "rien n'a été prévu" ?
Posté par Xavier Bestel (site web personnel) . Évalué à 10.
Je ne comprends pas cette phrase. Dans les protocoles NTP et PTP (quand ce dernier ne tracke pas TAI) tout est prévu pour l'ajout et le retranchement d'une seconde. Donc même si ça na jamais été utilisé en vrai c'est bien là, depuis très longtemps.
Dans un paquet NTP il y a 2 bits appelés "LI" (pour Leap Indicator). Les valeurs possibles sont généralement envoyées tout au long de la journée précédant un éventuel changement pour que le client soit sûr de les chopper:
Même chose pour PTP avec les "Announce Message" mais je vous passe les détails, c'est trop complexe pour un mini post.
[^] # Re: "rien n'a été prévu" ?
Posté par Denis Dordoigne . Évalué à 2.
J'avais écrit ça dans mes notes, je ne sais plus d'où ça vient (peut-être une citation de chercheur·se dans le magazine espiloon de novembre, je vais vérifier ce week-end)
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: "rien n'a été prévu" ?
Posté par Sébastien Koechlin . Évalué à 5.
Le problème n'est pas trop de diffuser l'information; mais que tous les systèmes ne se cassent pas la figure derrière.
La diffusion d'une seconde négative est susceptible de déclencher beaucoup de bugs.
Par exemple beaucoup de systèmes distribués se basent sur une horloge strictement croissante et ont un comportement qui n'est pas forcément défini dans le cas où le temps UTC revient en arrière.
[^] # Re: "rien n'a été prévu" ?
Posté par Xavier Bestel (site web personnel) . Évalué à 6.
Justement, pour l'instant il n'y a eu que des insertions de secondes supplémentaires ce qui est le cas le plus défavorable: la dernière minute fait 61 secondes, ce qui n'est pas vraiment prévu et oblige certains systèmes à "rejouer" la dernière seconde - d'où les bugs.
Le cas inverse (qui n'est encore jamais arrivé) c'est une dernière minute à 59 secondes, donc en gros on "saute" juste la dernière seconde ce qui est ultra facile.
[^] # Re: "rien n'a été prévu" ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 9.
Ce qui me semble incompréhensible dans cette histoire c'est que le temps ne revient jamais en arrière à cause des secondes intercalaires.
Il y a un temps qui s'écoule de 1 seconde toutes les secondes, c'est le temps TAI. Et UNIX compte aussi comme ça (depuis le 1er janvier 1970).
Ensuite il y a la conversion entre ce temps en secondes, et la date en années, mois, jours, heures, minutes, secondes. C'est cette conversion qui est impactée par les secondes intercalaires.
Donc, normalement sur un système correctement pensé, il ne devrait pas y avoir de problème, si les durées sont exprimées en secondes et basée sur le temps TAI?
On en viendrait presque à souhaiter que la colonisation de Mars démarre pour de bon et que les gens s'habituent à réfléchir avec plusieurs calendriers planétaires indépendants, des jours et des heures de longueur variable selon l'endroit…
[^] # Re: "rien n'a été prévu" ?
Posté par arnaudus . Évalué à 3.
Il y a un côté "bug de l'an 2000" là-dedans, non? Genre "ça n'a jamais été testé, donc ça risque d'être la cata", sauf que ça ne me semble pas hyper-évident de pourquoi ça serait le cas.
Sans compter que les systèmes savent gérer le changement d'heure, qui lui impose un retour en arrière et des trucs vraiment pas propres quand on "gagne" une heure (genre, il est deux fois 2h30 du mat dans la même nuit, là pour le coup le temps revient vraiment en arrière).
Après, j'avoue que je ne vois pas trop l'intérêt d'avoir des horloges synchronisées à la seconde près avec le temps astronomique. Pour quelle application de la vie courante tu as besoin de savoir à la seconde près quand tu passes sous un méridien? Dans la situation la pire possible (à l'équateur), une seconde c'est 500m de distance. À part pour les observations astronomiques, une telle précision me semble insensée : si tu veux communiquer avec des satellites ou des stations spatiales, il te faudra plus de précision de toutes manières, et si tu veux savoir l'heure qu'il est, tu te fous complètement de savoir que les 6 derniers mois ont duré une seconde de plus ou une seconde de moins. Il est évident qu'il faudra bien finir par compenser le décalage quand ça sera plusieurs heures (après tout, on tolère un décalage de +/-3h par rapport au soleil en Europe en fonction des pays), mais ça fait quelques millions d'années pour réfléchir à la question…
[^] # Re: "rien n'a été prévu" ?
Posté par Denis Dordoigne . Évalué à 7.
Si le bug de l'an 2000 a eu un effet limité, c'est parce qu'il a été identifié et corrigé dans les applications critiques (et a bien pété des SI mal patchés), la croyance qui voudrait que magiquement il ne se soit rien passé est un mythe
Ils savent convertir l'UTC en heure locale, depuis l'an 2000 on sait qu'on ne doit pas stocker les dates comme des chaines de caractères, on utilise dorénavant le nombre de secondes depuis epoch, ce qui n'est pas affecté par le changement d'heure (mais bien par les secondes intercalaires)
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: "rien n'a été prévu" ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Si seulement…
Les horloges matérielles (composants "real time clock") comptent toujours en années, mois, jours, etc. Les composants compatible avec l'an 2000 ont ajouté… 1 bit, pour dire si on est au XXè ou au XXIè siècle. Il est utilisé pour le calcul des années bissextiles (qui ne semblent poser problème à personne, elles? pourtant elles sont là pour une raison assez similaire)
[^] # Re: "rien n'a été prévu" ?
Posté par Alexandre Belloni (site web personnel) . Évalué à 3.
Ça n'est pas exact, il y a de nombreuses RTCs qui sont de simple compteurs de secondes.
Le problème des années bissextiles et celui des secondes intercalaires est complètement différent.
Pour les années bissextiles, on décide simplement qu'un jour est le 29eme du mois de février mais ce jour fait bien 84600 secondes et donc le temps est continu. Pour les secondes intercalaires, on rejoue deux fois la même seconde pour obtenir un jour de 84601 secondes et le compte n'est donc plus continu.
[^] # Re: "rien n'a été prévu" ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je suppose qu'il faisait allusion à l'affichage1 dans les BIOS… J'en ai vu en effet qui affichaient les dates en trois champs de deux, et quelques uns qui les affichaient en un champ de quatre et deux de deux mais celui de quatre était restreint dans un certain intervalle. Maintenant elles affichent un champ de quatre chiffres pour l'année.1
Concernant l'analogie, je ne comparerai pas au jour qui a le même nombre de secondes mais à l'année qui a du coup un jour en plus intercalé.
Dans les deux cas, les problèmes de discontinuité ne se posent que lorsqu'on passe d'un système (régulier) à un autre (moins régulier dans le même référentiel.) On observe le même phénomène quand on essaie de caler les horaires solaires (i.e. sur cadran solaire et suivant donc les longueurs de journées variables) avec nos horaires fixes (où la journée compte 84601 secondes découpées en minutes et heures égales) :s
Mais en interne, les horloges de nos machines électroniques sont bien de simples accumulateurs (au sens d'incrémentation de bits) d'un certain multiple d'oscillations (le quartz tout ça). Donc bien des compteurs de secondes (ou de fractions de seconde.) ↩
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: "rien n'a été prévu" ?
Posté par flavien75 . Évalué à 3.
Si on se base sur la norme "PC AT" d'IBM, les cartes mères doivent bien inclure un composant MC146818 ou compatible. A l'heure actuelle j'imagine qu'il doit être intégré dans le chipset (vu le nombre de transistors, ça coûterait probablement trop cher de souder un circuit indépendant).
Ce composant utilisait d'ailleurs un bit pour indiquer si l'heure d'été était appliquée ce qui évitait de boucler de 3h à 2h lors du passage à l'heure d'hiver. Le registre 32h contenait les deux premiers chiffres de l'année au format BCD (par exemple 0x19 en 1996).
À vrai dire, la RTC est le second composant que j'ai manipulé en programmation système, juste après le port Joystick. (et j'ai bien fait de garder ma bible du PC dans un coin).
Les vrais naviguent en -42
[^] # Re: "rien n'a été prévu" ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 04 décembre 2022 à 15:22.
Arf, j'ai encore la mienne mais perdu quelque part dans un carton (manque de place et déménagements réguliers tout ça) j'espère (parfois on découvre que des mites sont passées à certains endroit quand ce n'est pas l'humidité et plein d'autres choses)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: "rien n'a été prévu" ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 9.
Historiquement, pour la navigation maritime au sextant. C'est là l'origine du choix de mesurer le temps en synchronisation avec la rotation de la terre.
De la même façon que les années sont synchronisées avec la rotation autour du soleil pour des raisons principalement liées à l'agriculture et au suivi des saisons.
Donc en effet, la bonne solution ce serait de ne pas utiliser UTC dans les cas ou on a pas besoin de ça, et d'utiliser TAI. Pas de modifier UTC pour correspondre à ce qu'on veut faire…
[^] # Re: "rien n'a été prévu" ?
Posté par Alexandre Belloni (site web personnel) . Évalué à 3.
Non, du point de vue du système, le changement d'heure s'effectue comme un changement de timezone, l'heure du système reste en UTC et c'est l'offset qui est mis à jour. Le temps UTC reste donc continu, ça n'est pas le cas avec les secondes intercalaires.
[^] # Re: "rien n'a été prévu" ?
Posté par PR . Évalué à 2. Dernière modification le 26 novembre 2022 à 10:08.
UTC est parfaitement monotone p/r à TAI (temps atomique). Pas régulier, mais bien monotone.
Il s’agit juste d’augmenter, un peu, la tolérance sur UTC p/r à UT1 (le temps sidéral, rotation de la terre p/r aux étoiles), afin de ne pas faire de modifications UTC de court terme (ie. enlever une seconde, puis en ajouter une, puis…) alors qu’on s’attend, sur le long terme que la rotation de la Terre ralentisse (énergie perdue dans les forces de marée).
Edit : ce serait d’ailleurs bien de corriger la dépêche en ce sens d’ailleurs… :/
Mort aux cons !
[^] # Re: "rien n'a été prévu" ?
Posté par Denis Dordoigne . Évalué à 4.
Je viens de vérifier dans epsiloon, les sources sont Ahmad Byagowi de l'open compute project et de « nombreux ingénieurs que nous avons interrogés »
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: "rien n'a été prévu" ?
Posté par barmic 🦦 . Évalué à 4.
Il me semble que NTP ne fais pas la même chose. NTP synchronise une machine avec un temps de référence. Il ne s'intéresse jamais au calendrier lui même. NTP ne s'intéresse pas à la date, mais au temps passé depuis époque. Le fait qu'il y ai une 61ème seconde dans 1h ou qu'il n'y en ai que 59 ne l'impact pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: "rien n'a été prévu" ?
Posté par PLuG . Évalué à 4.
En 2012 on en parlait deja. https://linuxfr.org/users/nono/journaux/leap-second
à l'époque la leap-second avait fait planter les kernel linux et cela s'était vu sur la toile (tweeter, facebook, …).
dans mon entreprise aussi on avait eu des machines plantées. C'est bien ntpd qui déclenchait la prise en compte de cette seconde supplémentaire, le kernel tout seul ne savait pas qu'il fallait déclencher cette subtilité. Du coup les machines sans ntpd n'avaient pas le soucis.
# Seulement un décalage ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Si je comprends bien, la valeur d'une seconde UT1 est variable. Parfois plus courte que celle de la seconde UTC, parfois plus longue.
Avec une définition commune du jour (24 heures de 60 minutes de 60 secondes), ces deux temps se retrouvent normalement en décalage. Pour le moment, on a toujours géré des cas où UTC était en avance sur UT1, et on l'a recalé en lui ajoutant une seconde de temps en temps.
On parle donc d'une simple translation d'UTC. C'est bien si la durée de la seconde UT1 reste en moyenne assez proche d'une seconde UTC. Mais si, disons, la rotation de la Terre diminue pendant un moment, c'est plus qu'un simple décalage, qu'il faudrait, c'est une modification de la définition de la seconde.
En somme, au lieu d'ajouter ou de retirer une seconde de temps en temps, on parle d'ajouter ou de retirer un paquet de secondes à un moment donné, c'est ça ?
[^] # Re: Seulement un décalage ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Oui, en s'arrangeant pour que le "moment donné" soit au moins après le départ en retraite de la personne qui a pris la décision, et peut-être même avec un peu de chance après l'extinction de l'espèce humaine, comme ça on est certains que ce sera le problème de quelqu'un d'autre.
[^] # Re: Seulement un décalage ?
Posté par Denis Dordoigne . Évalué à 3. Dernière modification le 29 novembre 2022 à 10:43.
Actuellement la seconde est ajoutée lorsque UT1 - UTC >= 0.9 ; l'idée est d'augmenter le décalage autorisé pour être tranquille au moins les 100 prochaines années. Meta milite pour passer à 3600, ça permettrait de tenir quelques milliers d'années.
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: Seulement un décalage ?
Posté par Nucleos . Évalué à 3.
Voir l'avis étonnamment détaillé de David Madore : http://www.madore.org/~david/weblog/d.2022-11-20.2738.cgpm27.html#d.2022-11-20.2738
# lien cassé ?
Posté par anubis . Évalué à 3.
Le 1er lien semble cassé, il s'agit surement de https://www.bipm.org/documents/20126/64811223/Resolutions-2022.pdf/281f3160-fc56-3e63-dbf7-77b76500990f ?
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
[^] # Re: lien cassé ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Préfixes binaires
Posté par François . Évalué à 2.
Merci pour ce journal, j'étais passé à côté de ces informations.
Mais qu'en est-il des préfixes binaires associés à ces nouveaux préfixes?
Une rapide recherche n'ayant rien donné, je vous pose la question.
Pour rappel, les préfixes binaires définis par la CEI permet de lever l’ambiguïté entre les préfixes utilisant les puissances de 10 ou de 2.
1000 octets = 1 kilooctet = 1 ko (voire Ko mais le SI défini K comme kelvin)
1024 octets = 1 kibioctet = 1 Kio
Bref, cela donnerait à mon sens:
ronna -> robi
quetta -> quebi
[^] # Re: Préfixes binaires
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Attention que certaines interfaces affichent «
K» quand on n'affiche que les préfixe et que ce dont on parle n'a pas d'ambiguïté. Mais le préfixe est bien «k» …et on ne saurait avoir deKoMais effectivement, l'IEC a choisi Ki probablement parce-que c'est sans ambigüité dans un contexte où on ne manipule que des bits et des octets mais aucune des dimensions du SI (en plus leiqui suit ne correspond à aucune unité SI)N'empêche que c'est un peu perturbant, comme ce décamètre qui me fait parfois hésiter en me demandant pourquoi déci-are-mètres (même principe que le décimilimètre tombé en désuétude)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Accélération de la rotation terrestre
Posté par Alexandre Belloni (site web personnel) . Évalué à 3.
C'est bien l'inverse, la rotation de la terre a tendance à ralentir à cause des effets d'attraction luni-solaire et elle s'est accélérée inexplicablement ces dernières années, D'où le besoin de retirer une seconde intercalaires
[^] # Re: Accélération de la rotation terrestre
Posté par Denis Dordoigne . Évalué à 2.
C'est ce que j'indique après, mais effectivement ça aurait été plus clair si j'avais écrit « ayant eu tendance » pour bien fixer l'intervalle concerné entre les débuts de l'UTC et la dernière seconde intercalaire.
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: Accélération de la rotation terrestre
Posté par Alexandre Belloni (site web personnel) . Évalué à 2.
Non, il faut bien corriger la dépêche:
la rotation de la terre a tendance à décélérer depuis la mise en place de UTC: la seconde TAI (et donc UTC) est basée sur la vitesse de rotation moyenne de la terre entre 1750 et 1892.
C'est bien l'inverse, c'est parce qu'elle accélère qu'il faut supprimer une seconde.
[^] # Re: Accélération de la rotation terrestre
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
[Casquette modératrice on]
Bon alors, on remplace quoi et où ?
[Casquette modératrice off]
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Accélération de la rotation terrestre
Posté par Denis Dordoigne . Évalué à 3.
Effectivement je me suis trompé, peux-tu s-il-te-plait intervertir accélérer et décélerer ?
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: Accélération de la rotation terrestre
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5.
C'est fait, merci. Mais c'est mieux quand on a plus de précisions pour trouver les endroits à modifier.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Accélération de la rotation terrestre
Posté par Denis Dordoigne . Évalué à 2. Dernière modification le 02 décembre 2022 à 22:36.
J'ai un doute, je vais vérifier
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.