Date dans les API : Préci­ser l’heure et le déca­lage horaire

Date dans les API : Préci­ser l’heure et le déca­lage horaire

– Cette méthode donne la date et l’heure de publi­ca­tion
– L’heure dans quel réfé­ren­tiel ? c’est l’heure UTC ?
– Non, nous avons des conte­nus français, c’est l’heure française
– OK, je suppose qu’on parle de la métro­pole et de l’heure de Paris donc. Comment gérez-vous les chan­ge­ments d’heure légale ? Si je prends comme réfé­rence 2h30 du matin le 26 octobre 2014, je risque d’opé­rer certains trai­te­ments deux fois, ou dans le désordre.
– Pas de problème, nous livrons en réalité à des heures program­mées et il n’y a norma­le­ment pas de livrai­son entre 1h et 3h du matin, donc le cas n’ar­ri­vera pas.

Je brode un peu mais la conver­sa­tion a déjà eu lieu, plus d’une fois dans ma vie profes­sion­nelle. Je passe sur ceux qui ne compre­naient 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éci­ser l’heure et le fuseau horaire quand on donne une date dans un échange infor­ma­tique.

On peut argu­men­ter que trans­mettre toutes les heures en UTC pour­rait suffire, et que le fuseau horaire est super­flu. En pratique ce serait oublier une autre règle essen­tielle : « tout ce qui peut être mal inter­prété le sera ». Un jour, quelqu’un pren­dra votre date et l’uti­li­sera 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 fonc­tionne et pas simple­ment renvoyer les respon­sa­bi­li­tés, il va falloir préci­ser.

Seule solu­tion : Préci­ser le fuseau horaire ou le déca­lage horaire. J’irai même plus loin : Le préci­ser direc­te­ment 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 para­mètre par défaut à l’en­voi qu’on reco­pie sans y penser. La conven­tion de base sur les échanges Inter­net 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’avan­tage de cette syntaxe est qu’il existe des solu­tions pour la lire dans tous les langages de program­ma­tion, et que toutes ou presque sauront gérer le déca­lage horaire correc­te­ment. Il faut être sacré­ment tordu pour tenter de l’ana­ly­ser soi-même et donc risquer d’igno­rer la partie liée au déca­lage horaire.

Même à l’écri­ture, préci­ser expli­ci­te­ment le déca­lage horaire va gran­de­ment limi­ter les erreurs d’inat­ten­tion ou d’in­com­pré­hen­sion liées aux ques­tions de fuseaux horaires.

De toutes façons il faut utili­ser UTC

Rien ne vous impose pour autant d’ac­cep­ter des heures avec n’im­porte quel déca­lage horaire. L’idée est unique­ment d’avoir une syntaxe expli­cite sur le réfé­ren­tiel utilisé.

Si vous souhai­tez impo­ser des heures UTC, faites-le. Tout ce que je vous demande c’est d’uti­li­ser une syntaxe expli­cite à ce niveau, et de reje­ter en entrée les dates qui ne seraient pas elles aussi expli­cite quant au déca­lage horaire.

Photo d’en­tête sous licence CC BY-NC-SA par John Britt


5 réponses à “Date dans les API : Préci­ser l’heure et le déca­lage horaire”

  1. 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.

  2. […] 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.  […]

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.