Dans  la nuit du 31 décembre, une seconde intercalaire sera ajoutée

Dans la nuit du 31 décembre, une seconde intercalaire sera ajoutée

Que ferez-vous de ce temps libre ?

Avatar de l'auteur
Sébastien Gavois

Publié dans

Sciences et espace

08/07/2016 3 minutes
61

Dans  la nuit du 31 décembre, une seconde intercalaire sera ajoutée

La nuit du réveillon du jour de l'An sera plus longue d'une seconde de plus cette année. En effet, la dernière minute du 31 décembre 2016 durera 61 secondes au lieu de 60, afin de rapprocher le temps astronomique à l’échelle de temps légal.

La dernière minute du mois de juin de l'année dernière n'a pas duré 60 secondes comme d'habitude, mais 61 secondes. « Cette seconde supplémentaire, ou « intercalaire » comme on la désigne, permet de raccorder le temps "astronomique" irrégulier lié à la rotation de la Terre avec l’échelle de temps légal » rappelle l'Observatoire de Paris. Le 31 décembre de cette année, rebelote.

En France, le changement aura lieu à 1h00 du matin

En effet, le Service de la Rotation de la Terre vient de publier un nouveau Bulletin-C afin d'annoncer qu'« une seconde intercalaire positive sera insérée à la fin décembre 2016 », du moins pour l'heure UTC (Temps universel coordonné). En France, avec l'heure d'hiver qui est en avance d'une heure sur UTC, nous serons déjà le 1er janvier 2017.

Voici le déroulement de la nuit lors de l'ajout de la fameuse seconde supplémentaire :

  • 1er janvier 2017 0h 59m 59s
  • 1er janvier 2017 0h 59m 60s (seconde intercalaire)
  • 1er janvier 2017 1h 00m 00s

Pour rappel, il n'est pas possible d'ajouter plus d'une seconde à chaque recalibrage, et cela ne peut être fait que le 30 juin ou le 31 décembre de chaque année. Depuis la mise en place de ce système en 1972, ce sera la 27e fois qu'une seconde intercalaire positive sera ajoutée. Les derniers remontent à juin 2015, juin 2012, décembre 2008, décembre 2005, décembre 1998, etc.

Le 1er janvier 2017, la différence entre l'heure UTC et le Temps Atomique International (TAI) sera alors de 37 secondes, contre 36 secondes actuellement. Si vous vous demandez ce qu'il se passe sur Internet pendant une seconde (en moyenne), le site Internet Live Stats vous donne des éléments de réponse : 7 267 tweets, 2 189 appels Skype, 36 286 Go de trafic, 55 000 recherches sur Google, etc.

Un changement généralement indolore qui est sur la sellette

Si ce n'est pas grand-chose pour la grande majorité des gens, cela peut avoir des conséquences plus importantes dans certains cas comme la navigation par satellite, les réseaux de télécommunication et les marchés financiers. Pour rappel, des discussions ont lieu afin d'éventuellement arrêter cette procédure, mais n'ont toujours pas abouti à l'heure actuelle.

L'Observatoire de Paris explique que, « si la seconde intercalaire était supprimée, UTC serait alors découplé de la rotation de la Terre et nous n’aurions plus à rajouter de secondes intercalaires ». Dans tous les cas, « la connaissance très précise de l’orientation de la Terre n’en demeurerait pas moins fondamentale » (voir cette actualité pour plus de détails).

Pour ce qui est de savoir quand une seconde sera de nouveau ajoutée, il faudra attendre une nouvelle mise à jour du Bulletin-C, ce qui arrivera forcément plusieurs mois avant son entrée en vigueur.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

En France, le changement aura lieu à 1h00 du matin

Un changement généralement indolore qui est sur la sellette

Commentaires (61)


Donc au lieu de “…3, 2, 1, bonne année!” il faudra dire “…3, 2, 1, 0, bonne année!”?




« si la seconde intercalaire était supprimée … nous n’aurions plus à rajouter de secondes intercalaires »



lol :)



(dredi toussa)


La fameuse horloge atomique.








Gritou a écrit :



Donc au lieu de “…3, 2, 1, bonne année!” il faudra dire “…3, 2, 1, 0, bonne année!”?





Ouais mais du coup t’auras l’air con peu importe si tu dis ça à 00h59 ou 1h vu l’explication de l’article concernant le décalage d’une heure de la France avec l’heure UTC.



 le Service de la Rotation de la Terre



&nbsp;Je ne savais pas qu’un tel service existait <img data-src=" />




Que ferez-vous de ce temps libre ? 





<img data-src=" />


Genial. Bonjour les bugs informatiques que ça va causer et que nous devs devrons nous taper pour rafistoler.<img data-src=" />


Ouep, même que s’ils se mettaient en grève, la terre arrêterait de tourner.








Tydher a écrit :



&nbsp;le&nbsp;Service de la Rotation de la Terre




 &nbsp;Je ne savais pas qu'un tel service existait <img data-src=">







Bah c’est eux qui pédalent pour que ça tourne. Heureusement qu’ils sont là !



Edit : grillé par DHKold <img data-src=" />



Au japon elle aura lieu à 25:00 ?



24:59:59

24:59:60

25:00:00



?








DHKold a écrit :



Ouep, même que s’ils se mettaient en grève, la terre arrêterait de tourner.









SrBelial a écrit :



Bah c’est eux qui pédalent pour que ça tourne. Heureusement qu’ils sont là !



Edit : grillé par DHKold <img data-src=" />







J’y avais pas penser.

Merci pour l’info, je dormirai bien ce soir :)



C’était l’hécatombe en juin 2015 ?


On ajoute une seconde, pas une heure <img data-src=" />


Dans mon entreprise, nos serveurs sous Debian 6 étaient dans les choux le 1er juillet au matin, CPU à 100% de façon inexpliquée !


Et ceux qui travaillent à ce moment, ils une seconde en heure sup? <img data-src=" />


Sur la question d’arrêter de mettre une seconde revient en gros a savoir si l’on veut complètement se séparer du rythme naturel de la nature et passer celui des machines …

On a déjà le TAI (machine) et TU(nature), le temps UTC fait le lien entre les 2.



Ça fait peut être aussi chier les ricain que ce soit les bouffeur de grenouille qui gère ça …


j’ai édité juste avant ^^’








gokudomatic a écrit :



Genial. Bonjour les bugs informatiques que ça va causer et que nous devs devrons nous taper pour rafistoler.<img data-src=" />





bah vu le nombre d’appli/libs/OS qui gèrent seulement les secondes de 0 à 59 au lieu de 0 à 60 pour la 61ieme seconde, voire des OS qui “rejouent” deux fois la secondes 59 en “reculant” le temps&nbsp; Ou la différence de temps en UTC/POSIX et ce que donne certains NTP qui freeze de la seconde (blocage à 00:00:00 pendant une seconde) et qui fout en l’air les applis sensibles au timestamp…&nbsp;https://tools.ietf.org/html/rfc7164





Que ferez-vous de ce temps libre ?



<img data-src=" /> ou <img data-src=" />, je suis pas encore décidé.








gokudomatic a écrit :



Genial. Bonjour les bugs informatiques que ça va causer et que nous devs devrons nous taper pour rafistoler.<img data-src=" />





Bah, vous les devs informatiques, fallait déjà coder les trucs proprement au début.

Là vous rattraperez seulement ce que vous avez codé avec les pieds et / ou pas pris en compte au début pour ecomiser 10 frappes de clavier <img data-src=" />



Encore des sous balancés par les fenetres par notre gouvernement&nbsp;#HollandeDémission


ils auraient pu la rajouter dans la nuit du 24 au 25 décembre : ça aurait donné plus de temps au père noël pour sa tournée.


Non, nous on se base sur des spécifications <img data-src=" />.

C’est pas notre faute si elles sont pourries et/ou incomplètes et/ou inexistantes (rayez la ou les mentions inutiles)








Altair31 a écrit :



Non, nous on se base sur des spécifications <img data-src=" />.



 C'est pas notre faute si elles sont pourries et/ou incomplètes et/ou inexistantes (rayez la ou les mentions inutiles)&nbsp;    



&nbsp;



<img data-src=" />



 des spec? c'est quoi ça?   





plus sérieusement ça peut réellement déranger les app qui joue sur les timestamp depuis le 1er janvier 1970 ces trucs non?



hs, mais il est prévu que nxi fasse un article sur la possible annonce de l’improbable nouvelle particule début aout ?








Altair31 a écrit :



Non, nous on se base sur des spécifications <img data-src=" />.

C’est pas notre faute si elles sont pourries et/ou incomplètes et/ou inexistantes (rayez la ou les mentions inutiles)





C’est le propre des spécifications d’étre à la fois pourries, incomplètes et inexistantes.

Une spécification qui ne répond pas a ces critères ne peut être que l’œuvre d’une divinité.

Ainsi si tu en trouve, ouvre un reliquaire !









Drepanocytose a écrit :



Bah, vous les devs informatiques, fallait déjà coder les trucs proprement au début.

Là vous rattraperez seulement ce que vous avez codé avec les pieds et / ou pas pris en compte au début pour ecomiser 10 frappes de clavier <img data-src=" />







Joli le <img data-src=" />



Dans de très rare cas ça peut entrainer des valeurs négatives la où on en attend pas et tout foutre en l’air.

Si tu te fie au deux dernier timestamp reçu , tu peut très raisonnablement penser que la valeur du plus récent sera plus grand que le moins récent, mais avec la leap second, c’est pas forcément le cas. Donc si tu t’en sert pour récupérer une durée en faisant la différence entre les 2 timestamp, tu peut te retrouver avec un nombre négatif quand la leap second arrive.


Malheureusement, non.

Très peu de développeurs, même sérieux, prennent en compte ce genre de truc.



D’ailleurs, les développeurs les plus sérieux prennent un bibliothèque spécialisée pour la gestion du temps parce que c’est une des pires horreurs à gérer. Un des problèmes survenu la dernière fois sur debian venait justement de la bibliothèque dédiée.



Accessoirement, faire un soft totalement indépendant de la notion du temps est loin d’être évident et c’est là le plus gros problème.








gokudomatic a écrit :



Genial. Bonjour les bugs informatiques que ça va causer et que nous devs devrons nous taper pour rafistoler.<img data-src=" />





Dans 99% des cas cela ne pose aucun problème si les machines sont connecté aux serveurs de date&heure ntp Peut être parle tu d’une entrée en BDD au moment pile poile de la seconde intercalée ?



En fait ça dépend pas mal du système de timestamp que tu utilise, mais par exemple l’heure UNIX&nbsp; recule d’une seconde lors de la leap seconde. La seconde est bien ajouté, mais pas sous forme d’une 60ème seconde, plutôt sous forme d’une nouvelle 59ème ou 1ère (00ème) seconde ^^.

En gros si ton programme reçoit des valeurs approximativement toutes les 400 millisecondes et qu’il doit dater chaque entrée, le temps exact avec la leap seconde sera (pour simplifier l’écriture je formate en Minute:Secondes.millisecondes) :

&nbsp;0:59.400 &gt; 0:59.800 &gt; 0:60.200 &gt; 060.600 &gt; 1:00.000 &gt; 1:00.400 &gt; ….



Sauf que ton programme, s’il se base sur l’heure UNIX (ou un autre format de timestamp) qui “prend en compte” cette seconde en “reculant dans le temps”, il va avoir comme timestamp :

&nbsp; 0:59.400 &gt; 0:59.800 &gt; 1:00.200 &gt; 1:00.600 &gt; 1:00.000 &gt; 1:00.400 &gt; ….



Donc si le programme fait une différence entre les 2 dernières dates il va avoir :

&nbsp;… &gt; 0.400 &gt; 0.400 &gt; 0.400 &gt; -0.600 &gt; 0.400 &gt; …



Après suffit que cette différence soit utilisée pour surveiller par exemple la pression d’un équipement, et l’alarme peut très vite être déclenchée pour rien, et en fonction des mesures à mettre en place si l’alarme se déclenche, ça peut être à la fois très couteux et très dangereux.

&nbsp;

C’est le genre de chose qui peut arriver dans les rares occasions ou la leap seconde se présente et qui est relativement simple à éviter (prendre l’absolu de la différence, ou vérifier que la valeur est pas négative et ignorer dans ce cas la). Mais comme l’a dit papinse : “Très peu de développeurs, même sérieux, prennent en compte ce genre de truc.”.

Dans le cas ou c’est possible, l’utilisation d’une librairie spécialiser dans la gestion du temps est un bon moyen d’éviter ce genre de problème.



Edit: orthographe et grammaire <img data-src=" />








boogieplayer a écrit :



Dans 99% des cas cela ne pose aucun problème si les machines sont connecté aux serveurs de date&heure ntp Peut être parle tu d’une entrée en BDD au moment pile poile de la seconde intercalée ?





Non seulement les données saisies au moment de la fameuse seconde, mais aussi le formattage /parsing de la date entre la version numérique et la version lisible. Et je ne parle même pas des vieux codes pourris qu’on doit reprendre qui se basent sur la version lisible (merci les doublons, déjà qu’il y a un code spaghetti pour les changements d’heure). Donc si on pouvait ne plus trop toucher à l’heure officielle, ce serait cool.



Aucun problème sur les serveurs Windows par contre&nbsp;<img data-src=" />







(ils devaient être “partis en vacances”)








gokudomatic a écrit :



Non seulement les données saisies au moment de la fameuse seconde, mais aussi le formattage /parsing de la date entre la version numérique et la version lisible. Et je ne parle même pas des vieux codes pourris qu’on doit reprendre qui se basent sur la version lisible (merci les doublons, déjà qu’il y a un code spaghetti pour les changements d’heure). Donc si on pouvait ne plus trop toucher à l’heure officielle, ce serait cool.





Aaaaahhhhh le doux métier de dev qui se tape la maintenance. Bon courage !



&nbsp;<img data-src=" />



Ton problème tient plus du code pourri que de la leap second.


Le problème se pose surtout pour les applis “temps réels”.

Mais aussi logs, et éventuellement base de données, systèmes de fichiers, …



Enfin que des trucs pas sensibles du tout en fait…&nbsp;<img data-src=" />&nbsp;<img data-src=" />


C’est super tout ces gens hyper intelligents qui bossent 1 jour / an .



&nbsp;








AmaCha a écrit :



Le problème se pose surtout pour les applis “temps réels”.

Mais aussi logs, et éventuellement base de données, systèmes de fichiers, …



Enfin que des trucs pas sensibles du tout en fait…&nbsp;<img data-src=" />&nbsp;<img data-src=" />





Fous moi tout ça à la mer ! ça sert à rien et ça prends de la place&nbsp;<img data-src=" />









AmaCha a écrit :



Le problème se pose surtout pour les applis “temps réels”.

Mais aussi logs, et éventuellement base de données, systèmes de fichiers, …



Enfin que des trucs pas sensibles du tout en fait…&nbsp;<img data-src=" />&nbsp;<img data-src=" />





Ouais, heuh, le mec qui développe une appli temps réel en se basant sur l’heure légale qu’il obtient en décodant depuis la représentation string HH:MM:SS au lieu d’utiliser les “ticks” système (qui eux sont garantis monotones) … comment dire … ben … c’est un peu bien fait pour sa tronche si ça se plante.









Tydher a écrit :



le Service de la Rotation de la Terre



 Je ne savais pas qu’un tel service existait <img data-src=" />







systemctl stop ServiceDeLaRotationDeLaTerre.service



oups…









Mithrill a écrit :



Plus important à mon sens que la seconde intercalaire, la question de l’heure d’été.





Surtout qu’avec le réchauffement climatique l’hiver va disparaitre, donc autant rester en hiver à l’heure d’été.



&nbsp;









33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



Ouais, heuh, le mec qui développe une appli temps réel en se basant sur l’heure légale qu’il obtient en décodant depuis la représentation string HH:MM:SS au lieu d’utiliser les “ticks” système (qui eux sont garantis monotones) … comment dire … ben … c’est un peu bien fait pour sa tronche si ça se plante.





Sauf que ce genre de gars, il est vite remercié quand ça pète. Mais après, il faut bien que quelqu’un s’en occupe. Et comme d’hab, c’est pour bibi. Mais le gars de départ, il s’en fout, il n’est plus là.



Pfff…

Encore un coup du gouvernement pour allonger la durée du quinquennat … <img data-src=" />


“le Service de la Rotation de la Terre” <img data-src=" /> je veux faire ça plus tard quant je serais grand <img data-src=" />


Lol ce poison d’avril ma bien fais rire


C’est un poisson périmé, sans sucre, ne le mange pas…



C’est ce que je me demande, je serai au boulot à ce moment là !


un dev à 1h00 du matin ? Je dirais plus un admin system d’astreinte qui va voir un certains nombre de serveurs faire pschitt.

Déjà vu le cas avec des JVM.


Le sysadmin sera aussi là, vu que c’est lui qui va réveiller le dev et lui dire de se ramener en urgence au bureau. Pis vu que le chef PHB n’est pas là, il faut bien quelqu’un pour engueuler le dev afin de le garder réveillé pendant qu’il fait les correctifs d’urgence. Et ça le prépare aussi pour le meeting d’urgence qui sera 8 heures après, avec le chef qui prend la relève du sysadmin.



Dev support, le plus beau métier du monde.<img data-src=" />








Mimoza a écrit :



Sur la question d’arrêter de mettre une seconde revient en gros a savoir si l’on veut complètement se séparer du rythme naturel de la nature et passer celui des machines …

On a déjà le TAI (machine) et TU(nature), le temps UTC fait le lien entre les 2.



Ça fait peut être aussi chier les ricain que ce soit les bouffeur de grenouille qui gère ça …







Au contraire, ils sont très heureux que ce soit le contribuable français qui paye le service <img data-src=" />



En tant que non-développeur <img data-src=" />, je n’arrive pas à bien comprendre le sens de ton message. Pourrais-tu m’expliquer stp ?



Je comprends le sens général de manque de fiabilité de la méthode "je pars de l'heure lisible", mais pas plus. J'ai lu que monotone signifie que le sens de variation reste constant à travers le temps.       






Dois-je en déduire que le tick système est un nombre toujours croissant tendant vers l'infini, tandis que l'aspect cyclique de chaque opérande de l'horloge (h 0&gt;24&gt;0&gt;24, m 0&gt;59&gt;05&gt;59 etc) pose problème, justement parce que tout le monde n'aborde pas de la même manière les secondes intercalaires ?     





Parce que, hormis la question des secondes intercalaires, je ne vois pas le souci vu que les cycles se font toujours dans le même sens (ou alors quelqu’un a mis en place un système à remonter le temps, auquel cas je veux bien faire beta-testeur <img data-src=" />) ?









gavroche69 a écrit :



Pfff…

Encore un coup du gouvernement pour allonger la durée du quinquennat … <img data-src=" />





Oh boy… Best comment of the day ! <img data-src=" /><img data-src=" />



Bah oui, j’ai pas grand chose à ajouter, c’est juste. Je m’offre néanmoins l’occasion d’étaler ma culture sur le sujet.



L’OS maintient l’heure “locale” pour l’affichage à l’utilisateur. Cette heure peut varier par à-coups tant en avant qu’en arrière pour diverses raisons (passage heure d’hiver / heure d’été, déplacement dans un autre fuseau horaire, p. ex.)



On peut éliminer une partie de ces problèmes en utilisant l’heure UTC qui n’est pas censée être ainsi décalée, mais on court toujours le risque que l’heure maintenue par le PC se désynchronise de l’heure UTC réelle. Cette horloge n’est donc, elle non plus, pas immunisée contre les variations abruptes, qui se produiront quand l’utilisateur (ou le démon NTP…) “remettra les pendules à l’heure”.



Une application qui veut conserver l’ordre temporel des événements indépendemment de ces possibles variations doit donc utiliser une base d’horloge qui garantit a minima que le temps ne recule jamais, et si possible de ne jamais bondir vers l’avant non plus. Sous Windows on utilise GetTickCount, sous Unix il existe une CLOCK_MONOTONIC qui fait essentiellement la même chose. Cette horloge a le désavantage qu’elle est totalement indépendante du temps légal (p. es. GetTickCount donne le nombre de millisecondes depuis le démarrage du PC, il revient donc parfois à zéro, mais jamais au cours d’une exécution du programme), et il faut conserver les deux temps : le temps “tick” pour trier / comparer en interne, mais le temps légal pour afficher.



Enfin et pour finir, un programme qui “reconstruit” l’heure en calculant 3600heure + 60minute + seconde aura du mal avec une seconde intercalaire, alors qu’un programme qui demande à l’OS de lui fournir une valeur prédigérée (nombre de secondes écoulées depuis un moment précis dans le temps) n’aura pas ce souci (tant que l’OS fait lui aussi correctement son boulot, évidemment)








33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



On peut éliminer une partie de ces problèmes en utilisant l’heure UTC qui n’est pas censée être ainsi décalée, mais on court toujours le risque que l’heure maintenue par le PC se désynchronise de l’heure UTC réelle. Cette horloge n’est donc, elle non plus, pas immunisée contre les variations abruptes, qui se produiront quand l’utilisateur (ou le démon NTP…) “remettra les pendules à l’heure”.



sous Unix il existe une CLOCK_MONOTONIC qui fait essentiellement la même chose. Cette horloge a le désavantage qu’elle est totalement indépendante du temps légal (p. es. GetTickCount donne le nombre de millisecondes depuis le démarrage du PC, il revient donc parfois à zéro, mais jamais au cours d’une exécution du programme), et il faut conserver les deux temps : le temps “tick” pour trier / comparer en interne, mais le temps légal pour afficher.



Ok merci ce sont ces deux éléments qui me manquaient pour piger le problème (c’est d’autant plus stupide que ce devrait être évident pour moi, vu que le dual-boot entraîne un décalage systématique de 2h de l’horloge système, donc j’aurais dû réaliser par moi-même que le gros souci vient de la désynchronisation heure “réelle” / heure pc… <img data-src=" />

Bref, merci d’avoir pris le temps. <img data-src=" /><img data-src=" />









Drepanocytose a écrit :



Bah, vous les devs informatiques, fallait déjà coder les trucs proprement au début.

Là vous rattraperez seulement ce que vous avez codé avec les pieds et / ou pas pris en compte au début pour ecomiser 10 frappes de clavier <img data-src=" />





+12000&nbsp;<img data-src=" />



Un reboot de tous les systèmes et il n’y a rien à faire.

Merci qui ?


Toi aussi tu mises sur l’économie ? <img data-src=" />







Drepanocytose a écrit :



Bah, vous les devs informatiques, fallait déjà coder les trucs proprement au début.

Là vous rattraperez seulement ce que vous avez codé avec les pieds et / ou pas pris en compte au début pour ecomiser 10 frappes de clavier <img data-src=" />