Données et accès
Ventes à minuit : fixer le fuseau avant de fermer le mois
Pour qui : DAF qui reçoit des transactions horodatées en UTC mais décide sur un mois local.
2026-11-08
Notre avis
Conserver l’horodatage source puis appliquer une règle de date métier documentée, sans retrancher un décalage fixe toute l’année.
Avant de corriger un écart de fin de mois, nous fixerions le fuseau qui fait foi et la date métier utilisée. L’horodatage reçu, la date locale de l’opération et la période retenue par l’entreprise sont trois informations à distinguer. Ne remplacez pas la première par la dernière : vous auriez besoin de l’instant original pour expliquer la frontière.
Dans l’ordre
- Horodatage et fuseau de référence
- Conversion par règle reconnue
- Bornes de période testées
Pourquoi
- La même opération peut changer de jour selon le fuseau.
- Un décalage fixe peut échouer lors d’un changement d’heure.
Ce qui change le choix
Un reporting mondial peut choisir UTC si les utilisateurs l’acceptent et si les autres sources suivent la même règle.
Le même instant, deux mois possibles
Exemple fictif : une opération porte l’instant 30 juin à 23 h 30 UTC. Avec une règle de restitution à UTC+2 pour cet instant, elle devient le 1er juillet à 1 h 30. Elle appartient donc à juin si le reporting suit UTC, à juillet s’il suit cette date locale. Aucun des deux classements ne prouve, à lui seul, une erreur. Le mauvais résultat est le mélange : certaines sources suivant UTC et d’autres une date locale sans convention visible.
| Information conservée | Valeur fictive | Usage |
|---|---|---|
| Instant source | 30/06 à 23 h 30 UTC | Reproduire l’événement |
| Décalage retenu pour cet instant | +02 h 00 | Conversion explicitée |
| Date métier obtenue | 01/07 | Affectation selon convention approuvée |
Un nombre d’heures n’est pas un fuseau complet
La documentation de DateTimeZone.SwitchZone décrit un décalage fourni en heures et minutes. Elle ne promet pas qu’écrire +1 ou +2 fasse appliquer automatiquement l’historique d’un fuseau nommé. Nous ne recommanderions donc pas d’ajouter un nombre d’heures constant toute l’année pour représenter une zone qui change d’heure. Faites préciser par le mainteneur où résident les règles datées et comment sont traités les instants ambigus ou incomplets.
Une facture n’utilise pas forcément la date de son paiement
Le métier doit aussi choisir quel événement déclenche la période : commande, livraison, facturation ou paiement. Le fuseau ne tranche pas ce choix. Un paiement à minuit peut expliquer un rapprochement bancaire sans déterminer le mois de facturation. Gardez ces rôles de dates distincts plutôt que de renommer une unique colonne « date ». Les règles d’arrêté des comptes restent celles que votre responsable financier doit appliquer ; cette page propose une réception de données, pas une règle comptable.
Quatre cas à faire réceptionner
Demandez un instant juste avant la coupure, un juste après, un exemple à la période de changement d’heure pertinente et une source dépourvue de fuseau explicite. Pour chaque ligne, conservez la valeur brute, la règle datée appliquée, la date attendue et la période retenue. Comparez ensuite le détail et le total du mois. La réponse acceptable à une date insuffisante peut être « à qualifier » ; inventer le fuseau de l’émetteur ferait disparaître une incertitude utile.
Garder une solution proportionnée
Un relevé mensuel déjà arrêté par l’ERP peut ne pas nécessiter de conversion événement par événement. Il faut alors confirmer que les deux systèmes reprennent le même arrêté. À l’inverse, plusieurs canaux mondiaux peuvent imposer une convention commune plus élaborée. Nous choisirions la règle la plus simple qui permet de reconstituer les deux cas frontières, puis nous la relierions au dictionnaire des indicateurs et au dossier de clôture.
Limites
Analyse de documents publics et méthode éditoriale. Aucun compte ou logiciel testé ; exemples explicitement fictifs. Les paramètres et engagements propres à votre environnement restent à faire confirmer.
Prochaine action
Faites approuver un fuseau de référence, une date métier et quatre exemples frontières avant de recalculer les mois.
Preuves et sources
Faits lus, déclarations d’éditeurs, méthodes et avis restent distincts. Notre méthode.
Fait lu. DateTimeZone.SwitchZone utilise un décalage en heures et éventuellement minutes ; l’entrée doit comporter une information de fuseau.
Daté du 8 novembre 2026. Portée : Power Query M ; pas preuve d’application automatique des règles d’un fuseau nommé
Contexte : FR pour lecteur ; documentation officielle EN ou FR citée
Réserve : Lecture documentaire du périmètre cité ; aucun compte, test produit, contrat client ou performance mesurée.
Microsoft — DateTimeZone.SwitchZoneLu le 8 novembre 2026. Documentation primaire lue.
Portée : DateTimeZone.SwitchZone
Date du document : 2026-01-22.
Fonction de décalage explicite, pas une promesse de calendrier automatique Europe/Paris ou de règles d’heure d’été.
Notre calcul ou déduction. Conversion fictive : 30 juin à 23 h 30 UTC avec un décalage de +02 h 00 donne le 1er juillet à 01 h 30 ; aucune règle nationale de changement d’heure n’en est déduite.
Daté du 8 novembre 2026. Portée : Scénario fictif explicitement décrit ; calcul ou déduction éditoriale
Contexte : FR
Unité : Dates et décalages illustratifs
Réserve : Aucune consommation, facture ou expérience client observée ; exemple illustratif uniquement.
Notre méthode. Conserver l’horodatage source puis appliquer une règle de date métier documentée, sans retrancher un décalage fixe toute l’année. Le protocole proposé est notre méthode de réception.
Daté du 8 novembre 2026. Portée : DAF qui reçoit des transactions horodatées en UTC mais décide sur un mois local.
Contexte : FR
Réserve : Avis conditionnel et méthode éditoriale ; ne vaut pas test, validation juridique ou résultat garanti.