search

JC144 / EDF_Simulateur_Prix

Un outil pour simuler les différents Tarifs EDF depuis un export de la consommation.
GNU General Public License v3.0
154 stars 24 forks source link

Erreurs dans le parseur Enedis à cause du changement d'heure #82

Open zifnab0 opened 8 months ago

zifnab0 commented 8 months ago

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

zifnab0 commented 8 months ago

Autre problème illustré ici : image 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);

JC144 commented 8 months ago

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.

JC144 commented 8 months ago

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.

JC144 commented 8 months ago

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.

zifnab0 commented 8 months ago

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.