Erreurs dans le parseur Enedis à cause du changement d'heure
Opened this issue · 5 comments
Dans enedisParser.js, ligne 36, il écrit qu'il n'y a jamais de doublon chez ENEDIS. C'est inexact, cela se produit lors du changement d'heure d'hiver. Par exemple, dans mes données :
2023-10-29T01:00:00+02:00;120
2023-10-29T01:30:00+02:00;154
2023-10-29T02:00:00+02:00;126
2023-10-29T02:30:00+02:00;128
2023-10-29T02:00:00+01:00;146
2023-10-29T02:30:00+01:00;94
2023-10-29T03:00:00+01:00;164
2023-10-29T03:30:00+01:00;116
Ce qui a pour effet d'ignorer la consommation de deux mesures correspondant à l'heure du changement d'heure
Autre problème illustré ici :
au moment de la date du changement d'heure, setDate(date - 1 ) a pour effet de faire passer la date de GMT+1 à GMT+2. Ensuite, étant donnée que l'heure vaut "01:00:00", toISOString semble utiliser cette heure, y applique la timeZone (GMT +2) pour sortir une date en UTC qui est encore décalée d'un jour.
Ceci a pour conséquence d'ignorer la mesure du 29/10/2023 à 00:00 à cause du test de la ligne 37 et l'absence de else
La solution la plus simple me semble de remplacer :
formattedDate = isoDate.toISOString().split("T")[0].replace(/-/g, "/");
par
formattedDate = isoDate.getFullYear()+"/"+("0"+(isoDate.getMonth()+1)).slice(-2)+"/"+("0"+isoDate.getDate()).slice(-2);
Je vais regarder ça, merci pour le retour.
Ca peut être intéressant aussi de ne pas retirer si c'est lié à un changement d'heures.
Bon j'aurai pas le temps de tester mais le rapport Enedis donne bien le fuseau contrairement à celui d'EDF.
Je rajouterai un champ "originalDate" et je fera la comparaison dessus. Comme ça on aura bien un doublon d'heures pour la journée.
Par contre, il faut que je vérifie en sortie si on a pas une vérification sur un modulo du pas. Cela poserait problème si on se retrouve avec 50 pas au lieu de 48 par exemple.
Je confirme, on fait un modulo plus tard, la valeur ne change pas pour les 3 valeurs ajoutées en pas de 15. Du coup, le calcul pour la journée est encore plus éloigné de la valeur réelle.
Faute de mieux, je vais laisser cette approximation pour 2 jours dans l'année, mais je suis preneur de retours.
Je n'ai pas compris
la valeur ne change pas pour les 3 valeurs ajoutées en pas de 15
Attention, il y a deux problèmes distinct.
1er problème : les doublons
Ce n'est pas un problème d'avoir 50 entrées au lieu de 48 puisque le modulo donne toujours le même chiffre.
Par contre en y regardant de près, c'est pire pour le changement d'heure du printemps. Dans ce cas, il y a 46 entrées au lieu de 48, ce qui a pour effet que Math.floor(data[day].hours.length / 24) vaut 1 au lieu de 2 ! En remplaçant floor par round, le problème est corrigé.
2eme problème : le 'bug' de ISOString
il me semble que la solution que j'ai proposée permette de résoudre le problème.