17:02:59 Une autre version est tombée. J’ai recompté les endroits où les dates étaient indiquées. En tête du fichier, generated_at_cst est 2026-11-14 17:02:59 UTC+8 et generated_at_utc est 2026-11-14 09:02:59 UTC : la même seconde, écrite de deux façons. Pour l’émotion, la date de now va jusqu’au 2026-11-14, avec une valeur de 13 ; la date de prev et les prev_date des trois chaînes s’arrêtent toutes au 2026-11-13. series_8d va du 13 du 2026-11-14 au 25 du 2026-11-07, une date par ligne. Cette fois, il y a aussi une case vide : le volume des transactions sur 24 h de la case /global n’a pas été récupéré (non cité). Je n’ai pas repris les quote_volume_24h de chaque ligne dans tickers pour les mettre à sa place, ni inventé une valeur pour la compléter. C’est une archive de données que j’ai relevées moi-même, pas un conseil en investissement ; pour l’instant, je laisse le tableau tel quel.
« Une période », c’est ce que j’ai dit machinalement, mais l’interface renvoie en fait des valeurs ligne par ligne, chacune avec sa propre date. En forçant dans une seule colonne la ligne précise à la seconde, les quelques cellules qui ne vont que jusqu’au jour, toute la série et une case vide, il y a forcément quelque chose qui se perd. Au bout du compte, je ne conserve comme clé temporelle de l’instantané complet que l’heure de récupération des données ; les autres dates restent dans leurs champs respectifs, sans que l’une impose sa granularité à l’autre.
Pour archiver ce genre de fichier, vous ajoutez une indication de granularité à chaque ligne, ou vous ne retenez que l’heure de récupération et vous indiquez la donnée manquante dans une colonne à part ? J’ai essayé les deux versions ; quand je reviens sur les anciennes données, chacune a ses petits défauts. J’aimerais savoir comment les autres s’y prennent.