Synchros d'horloges, fuseaux horaires et changement d'heure ét

[Mitrale]

Voili voilou.... ce pour conserver la qualité du sujet initial proposé par /user/22999-mp13850/'>MP13850 et intitulé "En réponse à Piles au lithium sur sa station météo ? Un plus ?", la discussion étant partie dans une toute nouvelle direction et tout à fait inattendue, je créé donc ce nouveau sujet...

"Dans quelle mesure la synchronisation DCF77 ou NTP (Network Time Provider) de nos horloges de station météo et de PC peut-elle influencer la qualité de nos graphes de données lors des changements d'heure été/hiver?"

Merci d'avance à /user/1052-sebaas/'>Sebaas de bien vouloir "déplacer" (ce dans la mesure du possible), la partie de la discussion partie en "live" du sujet précédent!

[MP84120]

Voilà qui est mieux ça évitera de s'en mêler les pinceaux 😊

[jackT]

Bonsoir, je reviens sur le raisonnement de mm91 que je ne comprends pas du tout .

Prenons le passage de l'heure d'hiver à l'heure d'été, en assumant qu'au même moment, à 2h00, l'heure du PC et l'heure de la station sont réglés en heure locale et donc changent :

Séquence de mesures consécutives en assumant un pas de 1 minute, en heure locale :

mesure 1 : 1h57

mesure 2 : 1h58

mesure 3 : 1h59

mesure 4 : 3h00

mesure 5 : 3h01

mesure 6 : 3h02

C'est exactement ce que j'ai avec une VP2 et un PC réglé en heure locale : un trou d'une heure, autant dans weatherlink que dans Wswin.

SI dans Wswin la séquence affichée, comme décrit par mm91 :

mesure 1 : 1h57

mesure 2 : 1h58

mesure 3 : 1h59

mesure 4 : 2h00

mesure 5 : 2h01

mesure 6 : 2h02

cela veut donc dire que dans le cas de mm91, pour une raison ou une autre, l'heure interne de Wswin ne fait pas de changement d'heure. Ou alors c'est l'heure envoyée par la station qui ne fait pas de changement d'heure. Ou enfin, c'est le logiciel de Lacrosse qui recorrige l'heure avant de l'envoyer à Wswin.

En reprenant le graphique de mm91 du 30 mars 2014 :

On voit l'heure du lever du soleil indiquée à 7h33 et l'heure du coucher vers 20h00. L'échelle d'heure du graphique, au lever du jour, est donc bien en heure d'été locale, puisque la veille, le soleil s'est levé aux alentours de 6h30 - heure d'hiver - à Paris (voir http://www.ephemeride.com/calendrier/solaire/19/horaires-du-soleil.html).

On peut donc assumer que la mesure affichée sur le graphique à 3h00, ainsi que les suivantes jusqu'à la fin de la journée, correspond à l'heure d'été.

Et la mesure affichée à 1h30? Correspond-t'elle à la mesure faite à 1h30, heure d'hiver? Très vraisemblablement.

Alors à quelle heure locale ont été faites les mesures affichées sur le graphique de 2h00 à 2h59? L'heure locale ayant passé instantanément de 2h00 à 3h00, il n'a jamais existé par exemple de 2h30 en heure locale...

Pour la mesure de 2h30 sur le graphique, si c'est 2h30 "heure d'hiver", cela voudrait dire donc 3h30 heure d'été, et il y a une valeur plus loin dans le graphique pour cette heure....

Si c'est 2h30 "heure d'été", cela voudrait donc dire 1h30 heure d'hiver, et il y a déjà une valeur avant pour cette heure....

Cordialement

[mm91]

Salut JackT

Toi qui habite près de la Suisse peux-tu nous dire si c'est une blague ou la vérité ?

(ça pourrait nous aider dans la compréhension du redoublement ou de l'absence de mesure sur nos stations lors du changement d'heure !)

Passage à l'heure d'hiver aux CFF

Dès dimanche prochain, l'heure d'hiver sera à nouveau en vigueur en Suisse. Dans la nuit de samedi 25 à dimanche 26 octobre, à trois heures, les horloges de toutes les gares s'arrêteront pendant une heure. Dans la région zurichoise, certains RER nocturnes circuleront deux fois.

Dans la nuit de samedi à dimanche, les trains de nuit en transit à travers le pays s'arrêteront pendant une heure dans une gare appropriée afin de continuer leur marche selon l'horaire, mais à l'heure d'hiver. Les voyageurs de ces trains profiteront d'une heure de sommeil supplémentaire.

Par contre, les trains régionaux qui circuleront pendant le changement d'heure poursuivront leur marche selon l'heure d'été jusqu'à destination. En tout, une vingtaine de trains seront concernés par ce passage de routine à l'heure d'hiver.

A 3 heures, toutes les horloges de gares s'arrêteront pendant une heure. Cette opération est commandée électroniquement à toutes les horloges. Au cours des dernières années, le changement d'heure biannuel n'a pas posé de problème aux CFF.

Dans la région zurichoise, dix trains RER nocturnes circulant après 3 heures seront répétés : ils circuleront une fois à l'heure d'été et une fois à l'heure d'hiver.

David Herrgott

Je l'ai lu ici:

http://www.webtrains.net/actualites.php?article=1000002042

(je répondrai à ton post plus tard....si je comprends comment fonctionne les trains Suisse !...)

[jackT]

Ce n'est pas tout à fait cela... les horloges sont reculées et non arrêtées ...

Au passage à l'heure d'hiver, les horloges des gares, de la même manière que celle de nos PC et stations réglées en heure locales reculent d'une heure à 3h00 pour revenir à 2h00 et effectuer une deuxième fois la tranche horaire 2h00-3h00. Voir cette l'info venant directement du blog des CFF : http://blog.cff.ch/heure-d-hiver/2014/10/25

C'est également ce que j'observe chez moi avec ma station : lorsque l'heure revient une deuxième fois sur 2h00, les mesures effectuées durant la nouvelle heure allant de 2h00 à 3h00 (heure d'hiver) écrasent celles effectuées lors du premier passage 2h00-3h00 (heure d'été). Selon l'évolution des valeurs mesurées à ce moment là, je peux parfois détecter cela par un petit saut des valeurs entre 1h59 et 2h00 , car un intervalle réel d'une heure sépare ces 2 mesures.

EDIT : pour ce passage à l'heure d'hiver, jusqu'en 2006, j'avais les données de 2h00 à 3h00 en double dans la version de l'époque de Weatherlink. En surveillance de fichier Weatherlink, seule une des 2 périodes est enregistrée. Il me semble que la deuxième écrase la première, mais je n'en suis pas 100% sûr...

[tudgur]

Voilà comment je vois le problème (sans chercher d'explication sur un tableur...) :

Au changement d'heure à l'automne, on passe de 2h59 à 2h00.

Wswin (puisque l'on parle aussi de ce logiciel, tout comme Weatherlink) enregistre les lignes de données à :

2h00

...

2h57

2h58

2h59

Puis il est à nouveau 2h00 !

Mais cette ligne de 2h00 est déjà enregistrée dans le fichier.DAT (et le fichier.wlk)

Et que se passe t-il au niveau du datalogger ?

WsWin ne va pas écraser cette ligne mais n'enregistrera la prochaine ligne qu'à 3h00.

(C'est là ma petite différence d'analyse avec celle de Jacques : il n'y a pas écrasement, mais peu importe)

Donc, pendant une heure, Wswin ne va rien enregistrer : ces données sont perdues.

Jusqu'à 2h59, on a les données de l'heure d'été et à partir de 3h00 les données de l'heure d'hiver.

Sur un graphique, tout peut être OK, mais une heure de données à été perdue.

[jackT]

(C'est là ma petite différence d'analyse avec celle de Jacques : il n'y a pas écrasement, mais peu importe)

Je viens de rajouter une petite correction dans mon post précédent :

Pour ce passage à l'heure d'hiver, jusqu'en 2006, j'avais les données de 2h00 à 3h00 en double dans la version de l'époque de Weatherlink. En surveillance de fichier Weatherlink, seule une des 2 périodes est maintenant enregistrée. Il me semble que la deuxième écrase la première, mais je n'en suis pas 100% sûr...

[tudgur]

J'ai effectivement vu ton Edit (sans h )

Je ne saurais plus dire ce qu'il se passait exactement quand mon PC et la console étaient en heure locale.

Wswin a toujours piloté directement la console et je n'utilise Weatherlink que de façon accessoire, bien que permanente.

Mais il me semble avoir constaté à plusieurs reprises, lors de manips, que Wswin n'écrasait pas des données déjà enregistrées.

Quant à Weatherlink, je n'ai jamais vraiment regardé...

Toujours est-il qu'en ayant le PC et la console en heure UTC, on est sûr de son coup et certain de ne rater aucune donnée puisqu'il y a continuité de l'heure et des enregistrements.

[mm91]

Je suis en train d'observer de (encore) plus près, sur mes graphiques, tous les changements d'heure (depuis onze ans).

Parce que en observant les tableaux de mesure, c'est moins facile (à l'œil) d'y repérer des anomalies Il faudrait faire un traitement Excel: manip intéressante !… (une idée de comment faire pour détecter une répétition ou un manque de une heure juste, dans une suite de lignes ?)

D'ailleurs dans mes tableaux (et sur l'échelle de temps des graphiques) il y a toujours continuité de l'heure (contrairement à l'exemple donné par JackT); c'est les discontinuités des mesures qu'il faut détecter.

J'ai déjà découvert (seulement 2 fois) des discontinuités (redoublement) mais qui se produisent la veille du changement d'heure ! (les deux fois le samedi à 19h25 – 20h25; pourquoi ?)

(je vous montrerai les enregistrements)

Ca veut dire qu'il faut peut-être que je cherche quelques jours avant (et après ?) les changements d'heure; ça complique le boulot !…(d'où l'intérêt de Excel)

Mais je suis prèt à reconnaître dès maintenant que ce que je disais précédemment (pas de discontinuité) est erroné ! (tout au moins dans certains cas).

(et que fonctionner en UTC résout ce (petit !) problème (OK avec Tudgur))

Je continue donc à chercher, mais en attendant si vous pouviez montrer vos propres enregistrements (Wswin32, Weatherlink…) où l'on voit des décalages, ça serait intéressant pour comprendre.

merci.

à suivre donc.

PS:

pour les CFF, je parlais surtout des trains (et non des horloges):

- ceux qui s'arrêtent pendant une heure ! ???????????

- et ceux qui circulent deux fois !???????????????

difficile à croire (quoiqu'avec les Suisses... )

[jackT]

PS:

pour les CFF, je parlais surtout des trains (et non des horloges):

- ceux qui s'arrêtent pendant une heure ! ???????????

- et ceux qui circulent deux fois !???????????????

difficile à croire (quoiqu'avec les Suisses... )

A la SNCF, les trains ne semblent pas circuler deux fois, mais ceux qui sont en route pendant le changement d'heure s'arrêtent aussi pendant une heure : http://www.sncf.com/fr/presse/fil-info/changement-heure-hiver

[Mitrale]

N'ayant vécu qu'un seul passage heure été/hiver depuis que j'ai ma station Davis, j'ai relevé dans mes fichiers d'archives (.wlk) une donnée particulière (ici la température) du 26/10/2014 de 00h00 à 4h00 par intervalle d'une heure. Puis j'ai observé à quelles heures elles étaient mémorisées et restituées dans WeatherLink et WeatherUnderground.

[align=center] [/align]

[align=center][/align]

Voici mes observations suite au passage d'heure été/hiver du 26/10 à 3h00:

Dans WeatherLink:

• Les archives wlk de WeatherLink ne semble mémoriser que l'heure "standard" c'est dire locale (GMT+1) et ce sans tenir compte des changements d'heure été/hiver.

• Les graphes de WeatherLink semble fonctionner sur ce même principe, je retrouve mes mêmes points de mesure exactement aux mêmes heures sur le graphe.

[align=center][/align]

Pendant la période hiver, l'affichage des graphs correspond à l'heure locale.

Pendant la période été, l'affichage sera décalé avec une heure en retard. C'est à dire qu'une mesure effectuée par exemple à 15h (heure d'été) sera affichée sur le graphe à la position 14h.

[align=center] [/align]

[align=center] [/align]

Dans WeatherUnderground:

• Envoyées sur le site WeatherUndergound ces mêmes données semblent être mémorisées sur ce même principe sans tenir compte des changements d'heure été/hiver. Je retrouve dans les tables mes points aux mêmes heures mais décalées de 3 min.

• Pendant l'heure d'été, les graphes de WeatherUnderground montrent que mes mesures sont décalées d'une heure en arrière. Ils reviennent à l'heure pour redevenir synchro lors du passage à l'heure d'hiver à 2h00 du matin. Le graphe laisse ainsi apparaitre une discontinuité avec un saut de 1h00 à 2h00 du matin!

[align=center][/align]

Concernant le décalage de 3 min, j'ai contacté le support WeatherUnderground pour leur demander comment leur module installé (.dll) dans WeatherLInk leur envoie les données...

Pendant la période hiver, l'affichage des graphes correspond à l'heure locale (GMT+1).

Pendant la période "été", l'affichage est décalé avec 2 heures en retard. Une mesure effectuée par exemple à 15h (heure locale d'été) sera enregistrée dans la ligne 14h de la table (je m' attendais) pour être affichée à la position 13h du graphe, au lieu de celle à 15h!

Si mon raisonnement est exact, je pense qu'il s'agit là d'un bug... à moins que j'aie quelque part un réglage inapproprié!

[tudgur]

Ouh là !

Il faut s'accrocher, je n'ai pas tout compris.

Dans une semaine je serai de retour à Plouguerneau.

Avec mes deux consoles je pourrai donc faire des tests mais il semble que des logiciels différents aient des comportements différents face au changement d'heure.

Je ne sais plus exactement ce qu'il se passait sur mes graphes Wswin lorsque j'étais en heure locale.

Les quelques années ou j'ai fonctionné en heure locale, je pense que j'ai "corrigé" les graphiques.

Au passage à l'heure d'été, on passe directement de 1h59 à 3h00.

Si on considère qu'une "journée" commence à 0h00 et se termine à 23h59 celle-là ne dure donc que 23 heures puisqu'il manque la période allant de 2h00 à 2h59.

Je me trompe ?

Et donc, le jour du passage à l'heure d'hiver, la "journée" dure 25 heures.

Pourriez vous confirmer ou expliquer puisque Michel n'est pas d'accord avec ce raisonnement.

[Mitrale]

Ouh là !

Il faut s'accrocher, je n'ai pas tout compris.

Dans une semaine je serai de retour à Plouguerneau.

Avec mes deux consoles je pourrai donc faire des tests mais il semble que des logiciels différents aient des comportements différents face au changement d'heure.

Je ne sais plus exactement ce qu'il se passait sur mes graphes Wswin lorsque j'étais en heure locale.

Les quelques années ou j'ai fonctionné en heure locale, je pense que j'ai "corrigé" les graphiques.

Au passage à l'heure d'été, on passe directement de 1h59 à 3h00.

Si on considère qu'une "journée" commence à 0h00 et se termine à 23h59 celle-là ne dure donc que 23 heures puisqu'il manque la période allant de 2h00 à 2h59.

Je me trompe ?

Et donc, le jour du passage à l'heure d'hiver, la "journée" dure 25 heures.

Pourriez vous confirmer ou expliquer puisque Michel n'est pas d'accord avec ce raisonnement.

Je te rassure, moi aussi je n'ai pas tout compris... et te rejoins pour ta remarque concernant les logiciels différents!

En fait, c'est toute la chaine logicielle qu'il faut considérer, depuis la station (marque, modèle et firmware), l'appli qui collecte les données (WeatherLink, Weather Display, Wswin etc...) déclinées elles aussi dans des versions différentes) puis finalement la restitution graphique des données sur les sites météo ou perso, soumise quant à elle à l'entière créativité et compréhension du développeur...

Perso je porterai mon attention sur la chaine (VP2) ==> (WeatherLink) ==> (WeatherUnderground + InfoClimat + Météociel)

[jackT]

En ce qui me concerne, la chaine est la suivante : VP2 --> Weatherlink --> Wswin. Les données Weatherlink sont également exportée sur romma.fr. Donc les données de Wswin sont similaires à celle de Weatherlink.

Avec un réglage en heure locale, j'observe comme attendu le passage hiver --> été dans Weatherlink par un saut d'une heure, voir par exemple un extrait de mes données brutes de Weatherlink pour le 30 mars 2014:

Pour le passage été-->hiver, une heure de donnée est perdue, et comme indiqué dans un post précédent, je suspecte que le deuxième passage 2h00 --> 3h00 écrase les données du premier passage. C'est difficile à voir sur les données de la majorité des capteurs, mais j'ai remarqué plusieurs fois un saut dans la mesure de la température intérieure : la nuit, le chauffage étant arrêté , la température intérieure décroît de manière régulière, et je remarque lors du changement d'heure un "saut" entre la mesure de 1h50 et celle de 2h00, suggérant que la mesure capturée à 2h00 locale a été faite 1h10 après celle capturée à 1h50 locale et donc que les mesures capturées précédemment pour cette heure sont écrasées :

[Mitrale]

Bonsoir jackT,

Qu'appelles-tu un "réglage en heure locale"? Le saut d'une heure que t'avais observé le 30/03/14 implique l'écrasement d'une heure de données le 26/10/14. Je ne l'ai pas vu, les "timestamp" (heures de relevé) étant contigües... ben ça change tout! Merci pour l'info, je reverrai mon raisonnement demain avec je l'espère, une meilleure compréhension!

Cordialement,

[Cyrilleb]

En ce qui me concerne, j'utilise la VP2 avec le logiciel weatherlink uniquement.

Au début, la console était réglée en heure légale, avec changement d'heure activé.

En regardant les données dans weatherlink, je confirme bien ce qui est dit au-dessus:

- Lors du passage à l'heure d'été, il n'y a pas de données de perdues, mais je passe de 1h45 à 3h (saut d'une heure)

- Lors du passage à l'heure d'hiver, il y a une heure de données de perdue, les données de 2h à 3h sont écrasées lors du changement d'heure

Pour remédier au problème, j'ai mis la console en heure TU, désactivé le changement d'heure, et j'ai fait la même chose sur weatherlink.com (je suis en weatherlink IP).

Par contre, je n'ai pas changé l'heure du PC, qui reste en heure légale.

Depuis que j'ai fait cela, je n'ai plus de trou ou de données manquantes, tout se passe bien lors du changement d'heure.

[tudgur]

Par contre, je n'ai pas changé l'heure du PC, qui reste en heure légale.

Depuis que j'ai fait cela, je n'ai plus de trou ou de données manquantes, tout se passe bien lors du changement d'heure.

Ce qui veut dire que WeatherLinkIP ne tient pas compte de l'heure du PC ?

Et comment fais-tu pour maintenir ta console à l'heure ?

[mm91]

..............................

................................

Au passage à l'heure d'été, on passe directement de 1h59 à 3h00.

Si on considère qu'une "journée" commence à 0h00 et se termine à 23h59 celle-là ne dure donc que 23 heures puisqu'il manque la période allant de 2h00 à 2h59.

Je me trompe ?

Et donc, le jour du passage à l'heure d'hiver, la "journée" dure 25 heures.

Pourriez vous confirmer ou expliquer puisque Michel n'est pas d'accord avec ce raisonnement.

Le jour du changement d'heure il y a rupture entre l'heure (qu'il est) et le temps qui passe. Il ne faut plus utiliser les deux à la fois.

C'est une notion complètement contre nature et c'est pour cela qu'il nous est très difficile, intellectuellement de raisonner et de comprendre (et donc d'expliquer !)

au passage à l'heure d'été:

tu dis:

"la "journée" commence à 0h00 et se termine à 23h59",

mais 0h00 c'est en heure d'hiver et 23h59 c'est en heure d'été (puisqu'on a changé d'heure)

et à 23h59 il est en fait 1h59 en heure constante.

et en enlevant le saut de 2h00 à 2h59 la journée fait bien 24 heures

A chaque fois que nous donnons une heure (y compris dans un tableau, de Weatherlink ou Wswin32…) il faut préciser chaque fois si c'est une heure d'été ou une heure d'hiver.

et en tenir compte pour le calcul d'une durée entre deux heures.

D'autre part,

j'ai bien noté (chez JackT et Cyrilleb, car chez Mitrale, le pas de une heure ne facilite pas la compréhension !)

que dans weatherlink il y a un saut dans l'affichage de l'heure (1h40…1h50…3h00…3h10)

cela m'appelle deux remarques:

1/

y a-t-il également un saut sur l'échelle de temps du graphique correspondant ?

(je n'en vois pas sur l'exemple de JackT, mais ce n'est pas le graphique qui correspond à son tableau)

2/ dans mes enregistrements (tableaux) et sur mes graphiques de Wswin32 il n'y a jamais de saut dans les heures (je lis toujours, par exemple: 1h50…1h55…2h00…2h05...)

Mais comme déjà dis je constate bien des sauts sur le graphique lui-même (pas sur l'échelle)

et ceci même si les sauts on lieu la veille du changement d'heure comme signalé précédamment)

Il me semble, dans le cas N°1 (weatherlink), que le saut devrait être soit sur l'échelle (et les heures du tableau), soit sur le graphique, mais pas sur les deux à la fois ?

Attention également:

(comme l'a bien fait remarquer Mitrale): il y a toute une chaîne et chaque étape peut être traitée différemment (et se compenser !?)

Je propose donc, pour faciliter la compréhension, que l'on ne parle, dans un premier temps, que de la première étape, c'est à dire l'enregistrement direct fait par la station.

1/ pour Davis: enregistrement Weatherlink (fichiers wlk.dat si je ne me trompre pas)

2/ pour Lacrosse (par exemple) enregistrements Heaweather (fichiers history.dat)

Et en plus en vérifiant que l'éditeur utilisé ne change rien !…je vous ai dit que j'avais déjà vu des différence d'affichage de l'heure suivant l'éditeur utilisé !)

et seulement ensuite les enregistrement avec Wswin32

(ou si vous ne parlez que de Wswin32, vérifiez que c'était la même chose dans l'enregistrement qu'il utilise)

(et si possible plus tard !.. les hébergeurs comme statIC, Wunderground, etc)

[Mitrale]

.../...Attention également:

(comme l'a bien fait remarquer Mitrale): il y a toute une chaîne et chaque étape peut être traitée différemment (et se compenser !?)

Je propose donc, pour faciliter la compréhension, que l'on ne parle, dans un premier temps, que de la première étape, c'est à dire l'enregistrement direct fait par la station.

1/ pour Davis: enregistrement Weatherlink (fichiers wlk.dat si je ne me trompre pas)

2/ pour Lacrosse (par exemple) enregistrements Heaweather (fichiers history.dat)

Et en plus en vérifiant que l'éditeur utilisé ne change rien !…je vous ai dit que j'avais déjà vu des différence d'affichage de l'heure suivant l'éditeur utilisé !)

et seulement ensuite les enregistrement avec Wswin32

(ou si vous ne parlez que de Wswin32, vérifiez que c'était la même chose dans l'enregistrement qu'il utilise)

(et si possible plus tard !.. les hébergeurs comme statIC, Wunderground, etc)

Tout à fait mm91 et personnellement je m'abstiendrai de toute modif de paramètre tant que je n'aurai pas une bonne compréhension du flux de données... jusqu'en bout de chaine (j'en ai trois).

[mm91]

A la SNCF, les trains ne semblent pas circuler deux fois,

Ah, mais je voudrais bien lever le doute !

La question était: "est-ce une blague ou la vérité ?"

Alors, et au CFF?

mais ceux qui sont en route pendant le changement d'heure s'arrêtent aussi pendant une heure : http://www.sncf.com/fr/presse/fil-info/changement-heure-hiver

Alors là je suis "sur le c*l" !

les trains qui s'arrêtent une heure ça prouve bien l'absurdité du changement d'heure !

(le même train ne s'arrêtaient pas une heure lorsqu'il y avait les horaires d'été et les horaires d'hiver)

J'imagine bien le pauvre voyageur qui a hâte de rentrer chez lui après une longue journée de travail, qui, toute l'année à un trajet de 50 minutes à faire, et ce jour là le train s'arrête et il arrive chez lui une heure plus tard (*)

(*)

Alors Tudgur ! voilà un très bon exercice:

1/ arrive-t-il à la même heure, puisque l'heure à changé ?

2/ arrive-t-il une heure plus tard ?

Si tu réponds t'as tout compris !....

[tudgur]

...mais 0h00 c'est en heure d'hiver et 23h59 c'est en heure d'été (puisqu'on a changé d'heure)

et à 23h59 il est en fait 1h59 en heure constante.

et en enlevant le saut de 2h00 à 2h59 la journée fait bien 24 heures

Je ne comprends pas du tout ton raisonnement !

Je raisonne en "segments"

Peu importe que le début de la journée, à 0h00 soit en heure d'hiver et la fin de la journée en heure d'été.

Toute journée commence bien à 0h00 et se termine à 23h59.

Si ce jour de changement d'heure, un patron demande à son employé de travailler toute le journée, c'est à dire de 0h00 à 23h59, dis moi donc combien d'heures il va travailler ????

Dans cette "journée", il y aura 23 "segments" d'une heure et non pas 24 puisque le segment de 2h00 à 3h00 n'existe pas !

Lorsque tu bossais, tu n'aurais pas apprécié que l'on passe de 9h59 à 17h00 ? Ta journée de boulot aurait été plus courte, non ?

Je te ramène donc à ton exercice !

[Mitrale]

J'ai installé un analyseur de trafic sur mon PC me permettant de suivre tous les échanges de données entre mon ordi et ma console VP2. On peut ainsi voir défiler des commandes LOOP 1, LOOP 30, DMPAFT etc... envoyés régulièrement par WeatherLink, puis en retour les réponses de la console sous la forme de "LOOP packets" et qui sont faciles à interpréter grâce au document ci-dessous... un vrai régal!

"Vantage Pro, Vantage Pro2, and Vantage Vue Serial Communication Reference Manual"

/applications/core/interface/file/attachment.php?id=19899'>VantageSerialProtocolDocs_v261.pdf

J'ai pour l'instant encore trop de profils "internet" actifs dans WeatherLink (avec des redondances) pour déterminer avec certitudes les éléments à l'origine de trafic.

VantageSerialProtocolDocs_v261.pdf

[mm91]

...............................................

............................

Je propose donc, pour faciliter la compréhension, que l'on ne parle, dans un premier temps, que de la première étape, c'est à dire l'enregistrement direct fait par la station.

1/ pour Davis: enregistrement Weatherlink (fichiers wlk.dat si je ne me trompre pas)

2/ pour Lacrosse (par exemple) enregistrements Heaweather (fichiers history.dat)

.......................................

et seulement ensuite les enregistrement avec Wswin32

....................................

pour confirmer que j'avais raison d'être prudent:

je viens de découvrir que pour le changement d'heure du 25 mars 2012:

je vous avais signalé que dans Wswin32 il n'y avait pas d décalage dans l'échelle des temps, mais qu'il y avait un décalage dans les graphique le samedi précédent (24 mars) à 19h20.

(et pas de décalage au changement d'heure entre 2 et 3 heures le dimanche matin)

Je viens de regarder dans le fichier history.dat de HW (l'équivalent de wlk.dat chez Davis):

et bien, le dimanche 25 mars je vois passer l'heure de 1h55 à 3h00 !

(donc comme dans l'exemple de JackT)

(et aucun décalage le samedi à 19h20)

Donc les deux (la station et Wswin32) sont bien traités différemment !

Et pourtant je peux vous affirmer que depuis toujours:

- la station change toujours d'heure automatiquement (avec DCF77)

- le PC change toujours d'heure automatiquement (heure légale de Windows synchronisée Internet)

Je vous informe que je suis en train de mettre au point un traitement Excel pour détecter automatiquement ce qui se passe dans les enregistrements à tous les changements d'heure:

traitement automatique de 23 tableaux (deux mois par année) de 9000 lignes de Havy Weather

et la même chose avec Wswin32

Si ça vous intéresse et si vous voulez apporter votre contribution, voir éventuellement cette discussion: http://forum.pcastuces.com/detecter_une_discontinuite_dans_un_tableau_horodate-f23s35012.htm

Il y a du boulot !….

[jackT]

y a-t-il également un saut sur l'échelle de temps du graphique correspondant ?

(je n'en vois pas sur l'exemple de JackT, mais ce n'est pas le graphique qui correspond à son tableau)

Oui, il y en a un bien sûr! Voici le graphique Wswin, mais c'est idem sur Weatherlink ( je rappelle que chez moi, Wswin est en mode surveillance de fichier et il est donc tout à fait normal que le comportement des 2 logiciels soit le même). Les 2 logiciels relient simplement par un segment le point mesuré à 1h50 à celui mesuré à 3h00, aucune mesure n'existant entre les 2 points. On le voit encore mieux avec les points de la direction du vent : aucune valeur affichée entre 2h et 2h50.

[mm91]

Je ne comprends pas du tout ton raisonnement !

Je raisonne en "segments"

Peu importe que le début de la journée, à 0h00 soit en heure d'hiver et la fin de la journée en heure d'été.

Toute journée commence bien à 0h00 et se termine à 23h59.

Si ce jour de changement d'heure, un patron demande à son employé de travailler toute le journée, c'est à dire de 0h00 à 23h59, dis moi donc combien d'heures il va travailler ????

Dans cette "journée", il y aura 23 "segments" d'une heure et non pas 24 puisque le segment de 2h00 à 3h00 n'existe pas !

Lorsque tu bossais, tu n'aurais pas apprécié que l'on passe de 9h59 à 17h00 ? Ta journée de boulot aurait été plus courte, non ?

Je te ramène donc à ton exercice !

D'accord, j'en reviens donc à mon exercice !

et tu as raison, c'est exactement la même question que celle du train,

1/ arrive-t-il à la même heure, puisque l'heure à changé ?

2/ arrive-t-il une heure plus tard ?

comme tu ne l'as (malheureusement) pas trouvée je te donne donc la (les) réponse(s):

1/ il arrive à la même heure (horaire) et c'est d'ailleurs pour cela que le train s'arrête !

par exemple s'il avait un rendez-vous à 9 heures du matin (heure d'été) et que le train ne s'était pas arrêté, il serait arrivé avec une heure d'avance.

Le train s'arrête pour pouvoir arriver à la même heure (horaire)

2/ mais il arrive bien une heure plus tard (en durée) (puisque pour le même voyage le train s'est arrêté pendant une heure).

Le jour du changement d'heure il y a rupture entre "l'heure" (horaire) et "l'heure" (la durée ou le temps qui passe).

Donc il faut absolument préciser de quelle "heure" on parle.

Exactement comme pour ta question:

"Si ce jour de changement d'heure, un patron demande à son employé de travailler toute le journée, c'est à dire de 0h00 à 23h59(*)

, dis moi donc combien d'heures il va travailler ????"

(*) non, ce n'est pas la même chose

.

Je lui demanderai simplement ce qu'il appelle travailler toute la journée ?

- s'il me répond "pendant 24 heures"(durée) alors il n'y a pas d' ambiguïté: c'est 16h (24 - 8) payées en heures sup. (+ les majoration de nuit !)..............(ah! la belle époque !....)

- s'il me répond "de 0h00 à 23h59"(horaire), je lui demanderai si c'est en heure d'été ou en heure d'hiver ?

C'est important (et c'est voulu !) cet apartheid car si on ne se comprends pas la dessus on ne peux pas se comprendre sur ce qui se passe dans nos enregistrements (si on ne fonctionne pas en UTC !)