– 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.
5 réponses à “Date dans les API : Préciser l’heure et le décalage horaire”
Merci pour toutes ces précisions !
Un poil plus loin. Toujours donner l’heure et la date en UTC. Cela évite tous les incompréhensions de DST, laisser les interfaces locales gérer les affichages en fonction des heures d’hiver, d’été qui ne sont pas les mêmes pour tout le monde et en même temps.
J’en parle justement. C’est une fausse solution. Déjà parce que ça n’empêchera pas tes interlocuteurs d’envoyer des dates locales, ou de te fournir des dates locales (ce cas étant encore plus délicat vu que tu vas te retrouver avec des erreurs dans ta propre base de données). Cas vécu à peu près à chaque fois.
Certains considèrent que par défaut ça devrait être de l’UTC, d’autres que ça devrait être du local, d’autres que « ça dépend du client, au serveur de s’adapter », et la plupart ne s’en préoccupent même pas. Dire « toujours UTC », et même l’inscrire dans la doc, c’est juste une façon de pouvoir dire « c’est de ta faute » à ton interlocuteur.
En pratique je ne suis même plus certain que c’est vraiment forcément la valeur par défaut à promouvoir. Souvent l’applicatif est local, et amené à le rester longtemps. C’est peut être ridicule mais les forcer à traiter les décalages horaires c’est leur imposer de se demander à chaque fois s’ils doivent ajouter ou retirer les heures. Cas vécu encore hier. Il y a pas mal de monde qui ont toute légitimité à travailler quasi entièrement en heure locale, y compris au niveau du développement. Je ne parle même pas des intelocuteurs « à moitié techniques », pas assez pour faire des conversions mais assez pour demander des données brutes.
Donc en fait : J’ai tendance à dire comme toi, mais avec une conviction assez faible. Mais surtout : peu importe. L’idée c’est de rendre ça explicite, et c’est pour moi bien plus important que de savoir si on règle ça par défaut sur UTC, l’heure finlandaise ou l’heure locale.
Je me rappelle d’ailleurs un débat lors de la mise en oeuvre de la nouvelle interface de date de PHP. L’auteur avait mis la date locale de Norvège (ou autre pays nordique) par défaut. L’argument était que personne ne devrait laisser le fuseau horaire par défaut, que c’était une erreur grave et qu’il n’y avait aucune raison que le système considère que UTC devrait être plus « juste » que la Norvège.
Je trouvais ça hallucinant au départ, l’expérience m’a appris que sa réflexion était loin d’être idiote. La question n’est pas tant de choisir le décalage horaire, que de savoir le rendre explicite et de savoir le gérer. Dans le même ordre d’idée, la plupart des bons cadres applicatifs que je connais ne se contentent pas de prendre UTC par défaut si rien n’est configuré : Ils ajoutent de gros messages d’alertes. Parce qu’en pratique, il y a de bonnes chances que ce soit un oubli ou une erreur, que celui qui veut UTC par défaut devrait le faire aussi explicitement que les autres.
hehe. Décidément on se lit mal.
Je te rejoins sur ce commentaire et c’est ce que je dis par « laisser les interfaces locales gérer les affichages ».
Je pense que la date dans le format du document doit-être en UTC. En revanche ce que les gens rentrent ou lisent doit être local si tel est leur choix.
[…] 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:59ZL’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. […]