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