Comments on Et pendant ce temps-là, la CGPM fait des bêtises et décide de casser le temps sur Terre (ou pas)

Je ne comprends pas trop pourquoi ce serait aussi problématique de reléguer la gestion du décalage entre l'UTC et le soleil aux fuseaux horaires. Plusieurs choses que tu avais écrites (danc ce post et sur Twitter) m'avaient déjà interloquées ; c'est ce tweet : https://nitter.lacontrevoie.fr/gro_tsen/status/1599107764692713472#m qui m'a finalement poussé à réagir :

"So we'll have even more time zone chaos, with offsets like UTC+00:59 decided at the national level."

Avec l'adoption du "temps des chemins de fer" au XIXème, nous avons de fait déjà abandonné l'idée que l'heure locale suive le soleil à la minute près : cette adoption a rendu cette correspondance précise à environ une demi-heure près seulement. Il y a bien un moment où Brest et Grenoble ont décidé de synchroniser leurs horloges, qui, pourtant, différeraient de trois quarts d'heure si elles suivaient le soleil… Et parfois c'est même pire : à Paris par exemple, le soleil culmine à 12h51 en hiver, à 13h51 en été… Sans parler de la Chine qui est tout entière sur un seul fuseau horaire.

Du coup, pourquoi voudrait-on rajouter un écart de quelques secondes ? À l'échelle du Royaume-Uni disons, quelle importance ça a si on décide de suivre l'heure de Greenwich où celle de London City ? (À moins que le décalage ne soit dans l'autre sens ? je ne m'en sors pas avec les signes là tout de suite.)

Je propose que si nécessaire tous les lundis d'années bissextiles se terminent non pas par une seconde mais par une sebinde qui vaut une kibimilliseconde comme un chacun sait. Le compte devrait y être à peu près.

« mais ça demande de réécrire tout le code informatique du monde »

→ Doucement avec l'hyperbole, quand même. La plupart du code informatique du monde se fiche de l'heure, et la majorité de la minorité qui ne s'en fiche pas s'accommode très bien d'une erreur absolue de quelques secondes et d'une erreur relative de quelques pourmille ou moins.

J'ai mal mimé 23:59:60, ce n'était pas cet ajustement que je souhaitais proposer (d'ailleurs 59:60 me paraît plus élégant/naturel).

Ma proposition voulait être "au lieu de dilater certains intervalles de temps, on peut en ajouter un qui d'habitude n'est pas attribué et lui mettre une étiquette qui préserve monotonie et injectivité, ou en retrancher un en cas de seconde intercalaire négative".

Mais je comprends, d'après ta réponse, que j'avais probablement mal cerné la nature précise du problème, d'où une réponse qui devait tomber à côté de la plaque.

@vicnent -> Ruxor a évoqué un tel événement ici : « Et tout ça n'est pas que théorique : l'insertion d'une seconde intercalaire avant le 1er juillet 2012 a causé … »
Je ne crois pas que CGPM fait des bêtises il faudrait juste avant d’en juger attendre que le sujet soit complètement traité par cette vénérable institution. Le besoin pour ce ce changement doit exister mais on ne le connaît pour l’instant.

En variante de ta proposition et de celle de Google, la suivante tiendrait-elle la route ?

En cas de seconde intercalaire ajoutée, on suit le temps UTC et durant la seconde intercalaire, le temps informatique est 23:60:00.XXX.

En cas de seconde intercalaire retranchée, on affiche tout simplement le temps UTC : on garde injectivité et monotonie, c'est juste la surjectivité qui bugge, l'instant 23:59:59.XXX n'étant pas attribué.

Merci pour le résumé et synthèse.

Est ce que tu as connaissance d'un événement repérable quelconque mais officiel ait été repéré à une date du type YYYY/MM/DD mais surtout 00:59:60 (genre pose d'un avion à tel aéroport, ou je ne sais quel truc qui DOIT être loggué officiellement à la seconde près (voire en dessous de fait) ?
(A la réflexion, en fait, mon premier problème est : mais quels pourraient être ces événements ?)