Je travaille actuellement sur une application d'agenda qui doit gérer une liste de tâches que l'utilisateur peut créer.
Dans toutes les applications d'agenda que j'ai utilisées (Outlook, Thunderbird, google calendar), il n'y a aucun moyen de définir une heure pour les tâches. On ne peut que fixer une date d'échéance pour la tâche.
Par exemple, la liste des tâches pourrait ressembler à:
Supposons que l'utilisateur se trouve actuellement dans le Australia\Sydney
fuseau horaire. Si l'utilisateur devait passer à un autre fuseau horaire, dites America\New_York
, est-il utile d'essayer de tenter de localiser ces dates dans les dates locales à America\New_York
?
Le problème avec ce qui précède est que 00:00 AM 12/24/2011 to 23:59 PM 12/24/2011
à Sydney correspond à 08:00 23/12/2011 to 07:59 24/12/2011
à New York.
Maintenant, au lieu d'avoir une tâche due sur 1 jour, nous l'avons sur 2 jours. C'est évidemment très déroutant pour les utilisateurs, mais je ne veux pas que les utilisateurs manquent les délais pour les tâches car ils sont dans un fuseau horaire différent, mais la date d'échéance a été fixée dans un autre fuseau horaire.
Quelle est la meilleure façon de faire face à quelque chose comme ça?
Vous devez laisser le "système" pour garder une trace des fuseaux horaires (et l'heure d'été d'ailleurs). Votre application doit simplement vérifier
if (System.TodayDate = Task.DueDate) then Task.Highlight('Due today!')
.
Je ne pense pas que ce sera un problème pour l'utilisateur, car le jour où il/elle voyage "avec le Soleil", le jour sera en fait plusieurs heures de plus. A son arrivée à l'aéroport de SFO, il lui restera encore quelques heures à parcourir avant la date limite.
Je recommanderais fortement qu'il termine les tâches avant il arrive comme SFO. Il y a de meilleures choses à faire à San Francisco que d'effectuer certaines tâches sur une liste de tâches ;-D
Quelques réflexions:
Vous devez stocker vos dates en UTC sur le serveur, quoi qu'il arrive. De cette façon, vous obtenez gratuitement le décalage de fuseau horaire en utilisant javascript pour effectuer la conversion sur le système de l'utilisateur.
La deuxième chose est que cela dépend de la façon dont vous calculez la date d'échéance. Utilisez-vous une durée ou une date fixe. Disons que vous êtes en Australie et que votre utilisateur est à New York. Si vous leur attribuez une tâche qui devrait prendre deux jours, ce jour est relatif. Cette tâche doit-elle être terminée à un moment précis ou dites-vous que vous avez 16 heures pour y travailler?
enfin, cela ressemble à des tâches que vous avez sont indépendantes du temps. Cela signifie que votre date d'échéance est un jour et n'a pas de composante horaire. Dans ce cas, vous ne souhaitez pas effectuer de conversion de fuseau horaire.
Vous afficheriez les tâches comme des événements. Dans 5 jours, les utilisateurs devraient voir à quelle heure commencent et terminent les tâches.
Il est temps de passer à UTC ?
Tôt ou tard, nous allons faire face à de nombreux autres problèmes sans norme.