Folie du fuseau horaire dans l'application de gestion des tâches
Je travaille actuellement sur une application de gestion des tâches qui permet aux utilisateurs de créer et d'affecter des tâches, de définir les dates de début et d'échéance et de suivre la progression du travail.
Dans mon application, les utilisateurs ne planifient pas d'heures, ils fixent simplement les dates de début et d'échéance du 10 octobre 2013 au 20 octobre 2013.
Les problèmes surviennent dans le cas où Reporter (créateur de tâche) et Assigné vivent dans des fuseaux horaires différents. En même temps, cela peut être mardi pour Reporter mais toujours lundi pour Assigné. Et vice versa.
De toute évidence, il existe deux façons de gérer les dates:
- Utiliser le fuseau horaire du serveur (ou des paramètres de compte) pour définir le jour en cours pour tous les utilisateurs
- Utilisez le fuseau horaire local de chaque utilisateur pour définir son jour actuel
Mais les deux voies mènent à une folie totale. Jetez un œil aux exemples:
La folie d'utiliser un fuseau horaire commun pour tous les utilisateurs:
- Disons, c'est lundi matin. Le destinataire ouvre sa liste de tâches. Soudain, il voit que toutes les tâches avec la date limite d'aujourd'hui sont marquées comme étant en retard! Il pense avoir toute la journée pour les terminer, mais ils sont déjà en retard!
- Le cessionnaire peut également voir les tâches avec la date de début mardi prévue pour aujourd'hui! Cela peut se produire si mon fuseau horaire est UTC-9 et le fuseau horaire du compte est UTC + 9.
- Dans d'autres combinaisons de fuseaux horaires, le destinataire peut voir les tâches dont la date de début est égale à la sienne, mais elles sont programmées pour demain.
La folie d'utiliser l'heure locale de chaque utilisateur:
- Le reporter vit en UTC + 9 et le cessionnaire vit en UTC-6. Si le journaliste crée une tâche qui doit être démarrée immédiatement (et définit aujourd'hui comme date de début), le cessionnaire obtient la tâche prévue pour demain car son heure locale est toujours hier.
- Supposons que la date de début de la tâche soit le 10 octobre. En même temps, son statut sera déjà "En cours" pour Reporter mais "Commence demain" pour le cessionnaire.
- Si Reporter crée un rapport avec les tâches actuelles du cessionnaire, l'application utilisera son heure locale pour définir aujourd'hui. Mais pour le cessionnaire, c'est peut-être déjà demain, donc ses tâches actuelles sont totalement différentes.
Ce problème a-t-il une solution? J'ai essayé des idées de conversion des dates dans le fuseau horaire de chaque utilisateur pour permettre à différents utilisateurs de voir la même date de début comme une valeur différente, mais cela ne fonctionne pas correctement dans tous les cas.
Enregistrez toujours les dates et les heures en UTC, en particulier lorsque vous travaillez sur plusieurs fuseaux horaires. Affichez les dates et heures dans le fuseau horaire de l'utilisateur.
Même lorsque vous enregistrez tout en UTC, que signifie "aujourd'hui"? Habituellement, les gens veulent que ce soit quelque part entre aujourd'hui à 0:00 et aujourd'hui à 23:59:59. Ce qui a immédiatement des implications pour quelqu'un dans un autre fuseau horaire, même avec une différence de fuseau horaire d'une seule (ou même demi-heure), une partie de cette journée sera à une autre date.
Ainsi, comme vous l'avez déjà découvert, vous ne pouvez pas utiliser uniquement la date pour enregistrer le début et les exigences dues. Peu importe l'heure à laquelle vous l'enregistrez, le jour diffère pour quelqu'un dans un autre fuseau horaire.
Lorsque j'attribue aujourd'hui comme date de début, ce qui doit être enregistré est "aujourd'hui à 0:00" en heure locale "traduit en UTC. Mais une grande partie de ce jour sera déjà révolue lorsque la tâche sera affectée. Ce qui sera d'autant plus donc pour un cessionnaire dans un fuseau horaire "antérieur". Pour les tâches affectées à une date de début future, vous pouvez utiliser la date plus l'heure de début du jour ouvrable de l'assignateur. Pour les tâches affectées aujourd'hui comme date de début, la date actuelle le temps doit être utilisé (tout est traduit en UTC lorsqu'il est enregistré dans la base de données).
Votre application doit avertir la personne affectant une tâche à quelqu'un dans un fuseau horaire différent si le jour ouvrable de cette personne est déjà (ou presque) terminé. Vous pouvez difficilement vous attendre à ce que quelqu'un commence quelque chose "hier". Il serait probablement utile que vous incluiez dans votre formulaire un échéancier indiquant les heures d'ouverture du cédant et du cessionnaire.