08:57 <grenoya> bonjour
09:38 <misc> grenoya: tiens, ç'est pour toi: https://developers.google.com/time/smear
09:38 <misc> ( https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html )
11:05 <grenoya> misc: quelle horreur : ça veut dire que les datations des données seraient fausses sur plusieurs heures...
11:05 <grenoya> je lirai le 2e lien plus tard
11:08 <misc> sur 20h, oui
11:11 <misc> (et le lien dit que Amazon et Microsoft implemente aussi le meêm systeme)
11:23 <grenoya> je comprends pour leur type de système, mais c'est pas une bonne idée pour tout
11:39 <misc> grenoya: clairement, et je pense que le plus gros risque dans ton cas, c'est si des chercheurs vont sur le dit cloud et/ou se disent "on va prendre ce serveur ntp"
11:41 <feth> Les chercheurs/ingés en séismicité ont pas déjà résolu ce genre de pb 42 fois ?
11:41 <feth> ou les astronomes...
11:43 <haypo> cool, nouvel an dure 1 seconde plus cette année, champagne !
11:43 <haypo> de plus*
11:45 <haypo> quand on parle de leap seconds, ça me fait penser à la chanson https://www.youtube.com/watch?v=JOEhtn23ONM 24h01 de Renan Luce ;)
11:45 <haypo> (bon, ça parle d'une minute en plus, pas d'une seconde, mais bon, faut pas chipoter hein)
11:45 <misc> feth: ce que j'ai retenu de la conf de grenoya , c'est "bon, faut aller boire"
11:47 <feth> on pourrait pas simplement arrêter d'utiliser le temps des humains sur les ordinateurs (science, fiscalité etc) ? c'est biologique qu'on ait besoin de savoir en quelle saison on est, s'il fait jour etc à partir de la date et de l'heure
11:47 <feth> mais pour une machine, un temps monotone est suffisant
11:47 <mathieui> feth, parce qu’après devoir faire la corrélation c’est chiant
11:48 <feth> Y a des ordinateurs pour ça :)
11:49 <haypo> feth: UNIX, genre time(), compte un nombre de secondes depuis 1970
11:49 <feth> pis j'aimerais bien revenir au temps solaire local
11:49 <haypo> feth: c'est plutôt monotone nan ?
11:49 <feth> haypo: oui, et c'est simple et efficace
11:49 <haypo> feth: d'ailleurs, après des années de recherche, je ne sais toujours pas dire si time() donne le temps local ou UTC, ou bien si time() compte les secondes intercalaires ou non
11:49 <feth> (sauf si tu cherches à convertir des dates antérieures à 1500 etc)
11:50 <haypo> il me semble que POSIX ignore royalement les secondes intercallaires, genre "demerdez vous"
11:50 <haypo> feth: "on pourrait pas simplement arrêter d'utiliser le temps des humains sur les ordinateurs" t'as déjà vu des ordinateurs en 1500 ?
11:51 <feth> haypo: nan mais on a des chronologies de données scientifiques plus vieilles que ça
11:52 <feth> (carottes glaciaires etc)
11:55 <misc> je doute que ce genre de chronologie requiert un truc à la seconde pret
11:56 <feth> misc: tu proposes d'implémenter un temps unix en années en plus du temps unix en secondes ?
12:02 <feth> ou mieux, un temps IEEE 754
12:07 <maddingue> time() renvoie le nombre de secondes écoulées depuis Epoch -- http://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html
12:07 <maddingue> Epoch est définie comme 19070-01-01 00:00:00 UTC -- http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_150
12:07 <maddingue> et le calcul exact est indiqué ici : http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16
12:08 <maddingue> c'est donc basé sur UTC, mais comme cela ne tient pas compte des secondes intercalaires, ce n'est pas une vraie représentation de UTC -- https://en.wikipedia.org/wiki/Unix_time
12:11 <haypo> feth: à mon avis, tu veux plutôt une date genre année-mois-jour pour les données scientifiques
12:11 <haypo> maddingue: moi j'appelle ça "le bordel" surtout :)
13:24 <serge_sans_paill> haypo & antoine pirtrou qui trollent le C++ sur linuxfr, tsss
13:25 <serge_sans_paill> pitrou*
13:37 <haypo> serge_sans_paill: hihi
13:37 <haypo> serge_sans_paill: j'essaye de simplifie la vie aux auteurs de la prochaine dépêche
13:38 <serge_sans_paill> attends cest dépèches C++ sont chouettes
13:52 <feth> haypo: je pense qu'il faut pas dire à la place des scientifiques de quoi ils ont besoin. Si ça se trouve tu auras 3 données par jour sur des événements d'il y a 4000 ans
13:54 <nahuel> feth, haypo, à mon avis scipy a son format de stockage de dates < 1500
14:02 <grenoya> feth: d'accord avec toi pour le temps solaire local, mais comme répondu lors de ma conf : quand tu es dans un labo à répéter des expérience : OK pour ne pas avoir de lien avec le monde extérieur, mais en science de l'univers (les géoscience enfont partie) c'est qd même bien d'avoir un lien entre la date de la mesure et celle de ta montre
14:03 <feth> grenoya: Je suis pas sûr. Il faut un lien entre la date et la position des astres
14:03 <feth> et la température etc etc
14:04 <feth> mais arrêter de prendre pour axiomatique que les jours ont la même durée
14:04 <grenoya> ah mais si les ordinateur pouvaient gérer les leapsecondes proprement, je suis pour :)
14:05 <feth> si on remonte au temps des dinosaures, ce qui est pas complètement crétin d'un point de vue séries temporelles, la durée du jour, la durée de l'orbite lunaire... et donc les forces de marées n'ont pas les mêmes cycles qu'aujourd'hui
14:05 <feth> bah y a des bibliothèques pour faire la conversion au moment de la présentation des données à l'utilisateur :)
14:06 <grenoya> oui, mais chez nous l'unité de mesure va de la seconde à la microseconde (voire nano), alors c'est daté avec des GPS, donc en relation avec le temps humain
14:06 <grenoya> et cette représentation dépend de si tu tiens compte ou non des leapseconds
14:06 <feth> c'est pas en temps monotone les GPS ? grah
14:07 <feth> Bon, en tout cas avec la smear second, faut battre le record du 100m haies nage libre
14:11 <tshirtman> le temps, c'est nul, faut arréter d'essayer de le rendre cohérent
14:12 <tshirtman> il s'écoule même pas a la même vitesse selon qui l'observe, c'est dire
14:12 <feth> Oui à la fédéralisation du temps