– Cette méthode donne la date et l’heure de publication
– L’heure dans quel référentiel ? c’est l’heure UTC ?
– Non, nous avons des contenus français, c’est l’heure française
– OK, je suppose qu’on parle de la métropole et de l’heure de Paris donc. Comment gérez-vous les changements d’heure légale ? Si je prends comme référence 2h30 du matin le 26 octobre 2014, je risque d’opérer certains traitements deux fois, ou dans le désordre.
– Pas de problème, nous livrons en réalité à des heures programmées et il n’y a normalement pas de livraison entre 1h et 3h du matin, donc le cas n’arrivera pas.
Je brode un peu mais la conversation a déjà eu lieu, plus d’une fois dans ma vie professionnelle. Je passe sur ceux qui ne comprenaient pas qu’une date devait être soumise aux fuseaux horaires, parce que c’est en réalité toujours une heure (minuit précises) et que le 26 octobre n’est pas le 26 octobre partout en même temps.
Règle simple :
Toujours préciser l’heure et le fuseau horaire quand on donne une date dans un échange informatique.
On peut argumenter que transmettre toutes les heures en UTC pourrait suffire, et que le fuseau horaire est superflu. En pratique ce serait oublier une autre règle essentielle : « tout ce qui peut être mal interprété le sera ». Un jour, quelqu’un prendra votre date et l’utilisera comme une date locale et pas une date UTC. Promis, garanti. OK, ça ne sera pas de votre faute, mais si vous voulez que ça fonctionne et pas simplement renvoyer les responsabilités, il va falloir préciser.
Seule solution : Préciser le fuseau horaire ou le décalage horaire. J’irai même plus loin : Le préciser directement dans la date elle-même, pour qu’il ne puisse pas être ignoré à la lecture et qu’il ne puisse pas être un simple paramètre par défaut à l’envoi qu’on recopie sans y penser. La convention de base sur les échanges Internet c’est la section 5.6 de la RFC 3339.
Exemples simples :
2014–10–26T02:30:59+01:00 et 2014–10–26T01:30:59Z
L’avantage de cette syntaxe est qu’il existe des solutions pour la lire dans tous les langages de programmation, et que toutes ou presque sauront gérer le décalage horaire correctement. Il faut être sacrément tordu pour tenter de l’analyser soi-même et donc risquer d’ignorer la partie liée au décalage horaire.
Même à l’écriture, préciser explicitement le décalage horaire va grandement limiter les erreurs d’inattention ou d’incompréhension liées aux questions de fuseaux horaires.
De toutes façons il faut utiliser UTC
Rien ne vous impose pour autant d’accepter des heures avec n’importe quel décalage horaire. L’idée est uniquement d’avoir une syntaxe explicite sur le référentiel utilisé.
Si vous souhaitez imposer des heures UTC, faites-le. Tout ce que je vous demande c’est d’utiliser une syntaxe explicite à ce niveau, et de rejeter en entrée les dates qui ne seraient pas elles aussi explicite quant au décalage horaire.
Laisser un commentaire