🤔 Réflexions sur un problème de fuseaux horaires

mercredi 11 juillet 2018

Mon projet rewind.website est hébergé sur un site en Europe, c’est un souci potentiel pour le reste du monde.

Le site fonctionne ainsi : on fait une requête de flux RSS, où toutes les options sont dans l’URL, comme une sorte de ligne de commande. /<id du podcast>/<fréquence>/<date de début>/<option annexes>. L’ID du podcast, la fréquence et la date sont primordiaux dans cette requête. La date de début est aujourd’hui par défaut.

Le site est à l’heure de France, sur le fuseau horaire Europe/Paris, il suivra notre heure d’été et notre heure d’hiver. Si je lui demande un flux à partir d’une certaine date, il me servira le flux calculé pour 00:00 de cette date à l’heure de Paris. Un ami à Nouméa, ou un autre à Montréal, auront donc un flux qui ne sera pas bien calculé pour eux : il sera mis à jour dans la matinée à Nouméa, et en fin d’après midi de la veille à Montréal.

Il a donc fallu que je prenne en compte la gestion des fuseaux horaires.

Actuellement

Actuellement c’est plutôt basique, et en plus ça marche pas bien.

Lors de l’ajout d’un flux au site, dans les options à déplier, on peut fournir la date de début (aujourd’hui par défaut) via un <input type="date">, et le fuseau horaire (UTC+00:00 par défaut) via un gigantesque select avec autant d’options que de fuseaux horaires officiels, soit une bonne cinq-centaine. Le formulaire, qui devrait transmettre le fuseau horaire, n’est pas bien analysé, c’est un bug, il renvoie toujours UTC+00:00 au lieu de la valeur sélectionnée. C’est un bug que je corrige bientôt.

Lors de la création de l’URL, j’y ajoute le fuseau horaire selon ce modèle /<id du podcast>/<fréquence>/<date de début><decalage horaire>/<option annexes>, sous la forme +HHMM ou -HHMM, où HHMM désigne les heures et minutes. Le fuseau horaire de Kathmandu au Népal (UTC+05:45) sera donc noté +0545.

Lorsque le client de podcast fait une requête à cette URL, il va donc demander un podcast qui a pour date et heure de début : minuit, de cette date, avec cette différence par rapport à l’UTC.

Outre le bug sus-cité, il y a deux problèmes, l’un d’ordre UX, l’autre d’ordre plus général.

Le problème UX

La sélection d’un fuseau horaire est potentiellement chiante. 500 et quelques fuseaux, dans un <select>, c’est pas forcément intéressant. J’ai tenté de simplifier le choix en sélectionnant le bon fuseau par défaut, mais ça reste un <select> avec 500 options. Je n’ai pas essayé de l’ouvrir avec un smartphone des début, mais je crains le pire (en plus de ça c’est généré en JavaScript via deux dépendances, il faudrait que je passe ça côté serveur).

En plus de proposer le réglage par défaut, faut-il que je propose l’option de sélectionner le fuseau horaire ?

Un décalage avec l’heure UTC n’est pas un fuseau horaire

Aujourd’hui en France, on est en décalage UTC+2. Dans six mois, on sera en UTC+1, par la magie de l’Heure d’Été. Donc si je m’abonne à un podcast en janvier, je n’aurai pas le même résultat que si je m’y abonne en juillet. Si l’on aime l’exactitude, c’est pas idéal.

Mais on peut relativiser : le décalage n’est que d’une heure : au lieu d’être mis à jour à minuit, le flux RSS sera mis à jour à 23h ou 01h. Une solution pourrait être de déterminer l’heure de publication vers 3h du matin (heure locale)pour avoir toujours un podcast frais avec les croissants du matin, et ne pas être embarrassé quand on attend le podcast à minuit et qu’il arrive une heure plus tard.

Que faire ressortir de tout ça ?

Pour l’instant, à part le bug à corriger, je ne vais toucher au code que de manière minimale. Au lieu de dresser la liste du <select> via JavaScript, je vais faire ça du côté serveur. Ça fera une page qui aura plus de poids, mais deux dépendances en moins : moins de requêtes réseau et moins de poids inutile.

En revanche, pour mes deux problèmes je n’ai pas vraiment de solution.

L’UX de l’outil doit rester simple, donc le formulaire ne doit pas avoir trop d’options, juste le minimum. Est-ce que le choix de la date et du fuseau horaire font partie de ce minimum, ou sont-ils en trop ? Je n’en sais rien.

Est-ce que le souci de décalage d’heure d’été / hiver posera vraiment un problème aux utilisateurs de l’outil ? Là non plus je n’en sais rien, il va falloir voir à l’usage.

Une chose est sûre, c’est que faire simple, c’est vachement compliqué.

En parlant de faire simple alors qu’on peut faire compliqué, j’ai pas mentionné le problème des fuseaux horaires Linux, qui disent que le fuseau “Etc/GMT -5” se situe avec un décalage UTC+05:00, et de même pour tous les fuseaux “Etc/GMT”. J’ai mis du temps à m’en rendre compte, de celui-là.