changement d'heure

[jturlier]

Je souhaiterai que ce soit aussi simple !
Les fichiers wlk n'ont rien à voir avec les fichiers xnet ou cumulus, ce ne sont pas des fichiers "à plat", mais des structures complexes où chaque champ a des liaisons improbables avec d'autres champs.
Le problème c'est que j'ai été incapable de trouver mon bug et la moindre intervention dans ce petit coin peut entrainer un bug sur l'ensemble des données. Je suis déjà passé par là !

[muchistic]

Merci Jean pour ces explications

[Météo Villarzel]

Dominique, essaye d'ouvrir un fichier wlk avec notepad++ et tu comprendras le problème de Jean

Jean,
Pas de problèmes il suffisait juste de le savoir, j'ai cherché si le problème venait de chez moi avant de poster maintenant c'est bon la prochaine fois je laisserais couler un jour.

Par contre il me semble que je n'ai pas vu ce problème chez toi.

Bonne soirée

[jturlier]

Salut Pierre-André,

Par contre il me semble que je n'ai pas vu ce problème chez toi.

Normal, j'utilise Cumulus !!!

[Météo-Achiet]

Salut tout le monde

Jean, ne t'embêtes pas avec cette histoire de changement d'heure, si tout va bien, l'an prochain il n'y en aura plus!

[muchistic]

Salut tout le monde

Jean, ne t'embêtes pas avec cette histoire de changement d'heure, si tout va bien, l'an prochain il n'y en aura plus!

Bonsoir tout le monde
Justement, si il n'y a plus ce changement d'heure, VP2sql ne va t'il pas avancer d'une heure 24h plus tard ? et de ce fait plus à l'heure

[Météo Villarzel]

that is the question

[jturlier]

On règlera le problème le moment venu
D'ores et déjà je vais faire une modif des paramètres pour le prévoir !
Inch Allah

[PascalWMR]

Salut à tous

J'ai quand même vérifié ce problème.

Jean a raison, il n'y a pas de problème avec vp2sql
du moins au passage à l'heure d'hiver

.

Les tstamp se suivent correctement, les dates UTC également et les recdateTZ sont correctement calculés.
Pour ce qui me concerne, l'intervalle d'enregistrement des données étant de 5 minutes, il y a bien 300 secondes entre chaque tstamp. Que se soit en heure d'été comme en heure d'hiver.

Cependant, si vous regardez mon graphique http://www.monsite-meteo.eu/Page/graphdynnebulosite.php à la date du 28 octobre 2018, l'on constate qu'il y a moins une heure de décalage.
Sur ce même graphique, si vous allez à la date du 25 mars 2018, j'ai un décalage de plus une heure. Ces décalages n'apparaissent pas avant et disparaissent le lendemain.

Si l'on regarde mes autres graphiques dynamiques, on s’aperçoit que le changement d'heure a carrément disparu
Il devrait y avoir, sur les graphiques Highcharts, lors de ce changement d'heure 2 séquences allant de 02h00 à 02h55
Hors force est de constater que nada plus rien.

Par contre, lors du passage à l'heure d'été au mois de mars, il y a peut-être un petit cafard dans le calcul du recdateTZ. En effet, à 02h00 TZ on passe directement à 04h00 TZ au lieu de 03h00 TZ

Cependant, la suite des tstamp est correcte ainsi que les dates UTC



Par contre ce que je ce que je ne comprend pas, c'est que le changement d'heure au mois de mars est correctement interprété dans mes graphiques dynamiques .

Conclusion, je pense que c'est notre façon de recalculer les heures pour les passer en heures locale dans nos scripts PHP qui est en cause..
On se sert de la fonction PHP date("I"). Mais utilisons-nous correctement cette fonction

Code : Tout sélectionner

if (date("I",time())==0) { 
	$dTime[$i]=($list['tstamp']+3600)*1000;
	} 
else {
	$dTime[$i]=($list['tstamp']+7200)*1000;
  } 

A priori non (en même temps que je tape ce post je fait des recherches).
Je vais approfondir le sujet.

A+
Pascal

[jturlier]

Bonjour Pascal,
Il ne faut pas oublier le fait que les variables javascript sont chargées 2 fois puisqu'il y a 2 valeurs pour une même date et donc la seconde efface la première
Amicalement
Bonne journée
Jean