Apparemment, plutôt que de la bannir, il s'agirait plutôt de la gérer différemment, par exemple en l'étalant sur plusieurs heures.
Mais surtout je découvre qu'il arrive que la seconde intercalaire soit vers le passé, c'est à dire qu'on vit 2x la même heure UTC. Là oui je comprends que ça gueule. Ralentir l'horloge et étaler le décalage serait en effet bcp plus adapté.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Pas que le titre, il y a des allusions qui a une lecture rapide laissent penser que ce sont les sites et applis mal conçus qui doivent être préservés. Limite l'allusion aux versions 100 pour dire vous voyez les bogues ça vient de l'extérieur.
La seconde intercalaire est déjà le ralentissement. Par contre, ce n'est pas étalé et c'est un autre problème (choix/conventions d'implémentation de NTP)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par cosmocat .
Évalué à 3.
Dernière modification le 27 juillet 2022 à 11:00.
Cela fait 2 articles que je lis sur le sujet et j'ai un peu de mal à comprendre (je trouve que la séparation entre ce qui est proposé et ce qui est déjà en place pour éviter les problèmes n'est pas clair)
De ce que j'ai compris, ils proposent de ne plus gérer de secondes intercalaires et non pas, comme ils les font déjà, diluer (en mentant) la seconde intercalaire sur une période de temps.
Car si on les diluent, elle sont en quelques sortes toujours ajoutées et il y'a forcément des systèmes plus critiques où le mensonge n'est pas envisageable et donc qui devraient continuer à la gérer comme actuellement (donc je pense que ce n'est pas le sens de la proposition).
Et si elle est quand même ajoutée 'diluée' pourquoi un des ingénieurs de Méta dirait que sans la gérer, ce serait viable 2000 ans ? Si on en tient compte, ça devrait plutôt être viable de façon permanente, non ?
At Meta, we’re supporting an industry effort to stop future introductions of leap seconds and stay at a current level of 27. Introducing new leap seconds is a risky practice that does more harm than good, and we believe it is time to introduce new technologies to replace it.
et
As engineers at Meta, we are supporting a larger community push to stop the future introduction of leap seconds and remain at the current level of 27, which we believe will be enough for the next millennium.
Car si on les diluent, elle sont en quelques sortes toujours ajoutées et il y'a forcément des systèmes plus critiques où le mensonge n'est pas envisageable et donc qui devraient continuer à la gérer comme actuellement (donc je pense que ce n'est pas le sens de la proposition).
Les systèmes les plus critiques ne font jamais aucun changement d'heure ni ralentissement ni accélération. Ils gèrent une heure interne qui est stable et qui garde continuellement les propriétés dont ils ont besoin et convertissent l'heure quand il faut "sortir" cette heure.
C'est un peu comme changer ou non l'heure du bios quand tu change l'heure de ton OS.
Le changement climatique accélère la rotation de la Terre ce qui fait qu'il ne devrait plus y avoir de secondes intercalaires de toutes façons.
… mais pourquoi ces gens utilisent la mauvaise base de temps? Si les secondes intercalaires vous pose problème, utilisez le temps TAI et pas le temps UTC, il est prévu pour ça. Et laissez le temps UTC être synchronisé avec la rotation de la Terre, il est prévu pour ça. Si votre système n'est pas lié à la rotation de la Terre vous n'avez pas besoin du temps UTC.
… mais pourquoi ces gens utilisent la mauvaise base de temps? Si les secondes intercalaires vous pose problème, utilisez le temps TAI et pas le temps UTC, il est prévu pour ça.
Ce n'est d'ailleurs pas l’intérêt en C++ de la différence entre steady_clock (jamais de retour en arrière, monotonique) et system_clock (date/heure, qui peut être changée d'ailleurs, et déjà celui-la ne gère pas les secondes intercalaires).
La problématique semble montrer plus des erreurs de conception dans les logiciels qu'une difficulté à suivre la physique. L'exemple dans le lien en est la démonstration, ça pétera aussi si l'utilisateur change l'heure système ou si NTP se resynchronise et donc revient en arrière suite à trop grande fluctuation (qu'il faut donc quand même gérer).
# Titre un poil trompeur
Posté par gUI (Mastodon) . Évalué à 7.
Apparemment, plutôt que de la bannir, il s'agirait plutôt de la gérer différemment, par exemple en l'étalant sur plusieurs heures.
Mais surtout je découvre qu'il arrive que la seconde intercalaire soit vers le passé, c'est à dire qu'on vit 2x la même heure UTC. Là oui je comprends que ça gueule. Ralentir l'horloge et étaler le décalage serait en effet bcp plus adapté.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Titre un poil trompeur
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Pas que le titre, il y a des allusions qui a une lecture rapide laissent penser que ce sont les sites et applis mal conçus qui doivent être préservés. Limite l'allusion aux versions 100 pour dire vous voyez les bogues ça vient de l'extérieur.
La seconde intercalaire est déjà le ralentissement. Par contre, ce n'est pas étalé et c'est un autre problème (choix/conventions d'implémentation de NTP)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Titre un poil trompeur
Posté par Glandos . Évalué à 3. Dernière modification le 27 juillet 2022 à 09:43.
https://github.com/kdeldycke/awesome-falsehood#dates-and-time
Notamment https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time à la 33ème position, pour la version informatique (les compteurs qui dépassent leur capacité et retourne à 0), et à la 36ème position pour la version universelle.
[^] # Re: Titre un poil trompeur
Posté par cosmocat . Évalué à 3. Dernière modification le 27 juillet 2022 à 11:00.
Cela fait 2 articles que je lis sur le sujet et j'ai un peu de mal à comprendre (je trouve que la séparation entre ce qui est proposé et ce qui est déjà en place pour éviter les problèmes n'est pas clair)
De ce que j'ai compris, ils proposent de ne plus gérer de secondes intercalaires et non pas, comme ils les font déjà, diluer (en mentant) la seconde intercalaire sur une période de temps.
Car si on les diluent, elle sont en quelques sortes toujours ajoutées et il y'a forcément des systèmes plus critiques où le mensonge n'est pas envisageable et donc qui devraient continuer à la gérer comme actuellement (donc je pense que ce n'est pas le sens de la proposition).
Et si elle est quand même ajoutée 'diluée' pourquoi un des ingénieurs de Méta dirait que sans la gérer, ce serait viable 2000 ans ? Si on en tient compte, ça devrait plutôt être viable de façon permanente, non ?
[^] # Re: Titre un poil trompeur
Posté par cosmocat . Évalué à 4. Dernière modification le 27 juillet 2022 à 11:07.
L'article d'origine me semble plus clair et de ce que je comprends, ils proposent bien d'arrêter d'en ajouter:
https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-leave-the-leap-second-in-the-past/
et
Donc le titre de l'article n'est pas trompeur 😉
[^] # Re: Titre un poil trompeur
Posté par PR . Évalué à 1.
On dit que les cons ça ose tout…
Ils savent pas gérer UTC. Donc ils proposent de le supprimer. Lol. Faudrait leur expliquer que la Terre ne tourne pas autour de leur nombril.
Mort aux cons !
[^] # Re: Titre un poil trompeur
Posté par barmic 🦦 . Évalué à 6.
De ce qu'on m'avais expliqué.
Les systèmes les plus critiques ne font jamais aucun changement d'heure ni ralentissement ni accélération. Ils gèrent une heure interne qui est stable et qui garde continuellement les propriétés dont ils ont besoin et convertissent l'heure quand il faut "sortir" cette heure.
C'est un peu comme changer ou non l'heure du bios quand tu change l'heure de ton OS.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# discrimination
Posté par dj_ (site web personnel) . Évalué à 3.
En encore une fois, personne ne parle du premier intercalaire :(
[^] # Re: discrimination
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 27 juillet 2022 à 14:24.
Sans compter les gens qui rendent des copies simples…?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: discrimination
Posté par Thomas Douillard . Évalué à 2.
C'est pas le genre de la maison
# Chagement climatique
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8.
Le changement climatique accélère la rotation de la Terre ce qui fait qu'il ne devrait plus y avoir de secondes intercalaires de toutes façons.
… mais pourquoi ces gens utilisent la mauvaise base de temps? Si les secondes intercalaires vous pose problème, utilisez le temps TAI et pas le temps UTC, il est prévu pour ça. Et laissez le temps UTC être synchronisé avec la rotation de la Terre, il est prévu pour ça. Si votre système n'est pas lié à la rotation de la Terre vous n'avez pas besoin du temps UTC.
[^] # Re: Chagement climatique
Posté par Zenitram (site web personnel) . Évalué à 2.
Ce n'est d'ailleurs pas l’intérêt en C++ de la différence entre steady_clock (jamais de retour en arrière, monotonique) et system_clock (date/heure, qui peut être changée d'ailleurs, et déjà celui-la ne gère pas les secondes intercalaires).
La problématique semble montrer plus des erreurs de conception dans les logiciels qu'une difficulté à suivre la physique. L'exemple dans le lien en est la démonstration, ça pétera aussi si l'utilisateur change l'heure système ou si NTP se resynchronise et donc revient en arrière suite à trop grande fluctuation (qu'il faut donc quand même gérer).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.