Forum Discussion
Kuartz
Écho naissant
Écho naissantLe endpoint changelogs/supplier_invoices requiert une start_date en UTC et rfc3339
Bonjour,
il me semble constater une erreur sur le endpoint changelogs/supplier_invoices avec le paramètre start_date.
Il est dit dans la documentation :
The date should follow RFC3339 format.
Mais j'ai constaté que si le date/time passé n'est pas également en UTC, alors les indications de time zone sont ignorées et le date/time est traité comme de l'UTC, impliquant un décalage de deux heures par exemple si le date/time d'origine est en fuseau CEST.
Exemples :
Le date/time UTC RFC3339
2026-07-06T23:55:00Z
Est équivalent au date/time RFC3339
2026-07-07T01:55:00+02:00
Mais le endpoint va considérer le deuxième comme étant
2026-07-07T01:55:00Z
Et donc toutes les données situées entre 2026-07-06T23:55:00Z et 2026-07-07T01:55:00Z ne seront pas retournées.
Soit la documentation doit spécifier que le paramètre start_date doit être en UTC, soit le endpoint doit supporter correctement le RFC3339 en prenant en compte la time zone indiquée.
Merci
Bonjour Kuartz
Les endpoints de changelog (dont changelogs/supplier_invoices) utilisent la valeur de start_date telle qu'elle est fournie, sans la reconvertir en UTC avant de la comparer aux horodatages enregistrés (qui sont eux stockés en UTC). Il n'y a pas d'étape qui interprète l'offset de fuseau horaire du RFC3339 pour le ramener en UTC : la chaîne fournie est utilisée directement comme clé de comparaison.
Concrètement, un start_date fourni avec un offset non-UTC (ex. +02:00) est bien traité comme une chaîne littérale, ce qui produit exactement le décalage de deux heures décrit dans le message. La documentation publique de l'API indique seulement que la date doit suivre le format RFC3339, sans préciser qu'elle doit être en UTC. L'observation et la proposition (préciser dans la documentation que start_date doit être en UTC, ou faire en sorte que l'endpoint convertisse correctement l'offset de fuseau horaire) sont donc cohérentes avec le fonctionnement actuel du co
1 Réponse
- Angélique_
Pennylaneur
Bonjour Kuartz
Les endpoints de changelog (dont changelogs/supplier_invoices) utilisent la valeur de start_date telle qu'elle est fournie, sans la reconvertir en UTC avant de la comparer aux horodatages enregistrés (qui sont eux stockés en UTC). Il n'y a pas d'étape qui interprète l'offset de fuseau horaire du RFC3339 pour le ramener en UTC : la chaîne fournie est utilisée directement comme clé de comparaison.
Concrètement, un start_date fourni avec un offset non-UTC (ex. +02:00) est bien traité comme une chaîne littérale, ce qui produit exactement le décalage de deux heures décrit dans le message. La documentation publique de l'API indique seulement que la date doit suivre le format RFC3339, sans préciser qu'elle doit être en UTC. L'observation et la proposition (préciser dans la documentation que start_date doit être en UTC, ou faire en sorte que l'endpoint convertisse correctement l'offset de fuseau horaire) sont donc cohérentes avec le fonctionnement actuel du co
