Quel est le fuseau horaire approprié pour afficher les heures des événements en ligne?

Mon site Web propose régulièrement des événements programmés par les utilisateurs. En ce moment, nous utilisons notre fuseau horaire EDT (ou EST) comme fuseau horaire de base pour tous les événements sur le site. J'ai l'impression que c'est 1) faux ou 2) très déroutant. Actuellement, nous avons des utilisateurs partout aux États-Unis et en Europe.

La méthode appropriée pour localiser les heures est-elle basée sur le fuseau horaire des clients? utiliser UTC / GMT?

Merci

Honnêtement, il s'agit d'un problème fréquemment rencontré lors de l'utilisation d'un site Web par plusieurs fuseaux horaires. Il existe une longue liste de façons de surmonter la bataille. Pour résumer les badp, de nombreux facteurs contribuent à la façon dont les différents fuseaux horaires sont traités.

La plupart des sites Web optent pour l'une des deux solutions différentes pour résoudre ce problème:

1) Stockez tout ce qui implique une date au format UTC dans la base de données ... et autorisez un paramètre défini par l'utilisateur pour que les utilisateurs de votre site Web choisissent le fuseau horaire dans lequel ils se trouvent ... ou faites un peu de magie geo-ip-lookup pour le découvrir où ils se trouvent dans le monde et trouvez le fuseau horaire approprié ... et chaque fois que vous affichez la date ... assurez-vous d'appeler la fonction nécessaire à la localisation. Presque tous les langages de programmation ont une méthode pour afficher les dates en utilisant un fuseau horaire spécifié. Vous devrez également procéder de la même manière pour les utilisateurs insérant des dates. (prendre l'heure locale et reconvertir en UTC pour le stockage de base de données) C'est probablement l'approche la plus courante. Cela vous épargnerait également beaucoup de temps d'essayer de «réinventer la roue». En ce qui concerne les visiteurs anonymes ... vous pouvez soit A) coller avec EST / EDT (en utilisant les appels de fonction intégrés pour afficher le cas échéant) ou B) revenir à la fonction de recherche Geo-IP et choisir un fuseau horaire basé sur une supposition éclairée. C'est aussi une bonne idée de toujours spécifier le fuseau horaire dans lequel vous affichez la date / heure. Par exemple, ne dites jamais "12:00" ... assurez-vous qu'il indique "12:00 EDT"

ou 2) Suivez le modèle de stackexchange (et bien d'autres) pour afficher la différence entre maintenant et quand le message a été créé. c'est à dire au lieu de "posté le x date" ... vous feriez "il y a x heures" ou "x jours x heures" etc ... ou pour des dates futures ... "dans 6 jours 14 heures ..." devient rapidement plus courant dans de nombreuses situations ... mais n'est pas aussi idéal pour les horaires de type calendrier.

Bien sûr ... vous pouvez toujours adopter une sorte d'hybride des deux ... et vous devrez peut-être même aller plus loin et stocker les dates en utc ... mais également stocker un fuseau horaire spécifique pour un événement. En fin de compte, la décision vous appartient.

Voici le problème: l'UE et les États-Unis n'activent et ne désactivent pas l'heure d'été en même temps; en mars, il y avait une différence de trois semaines entre ces événements.

Voici ce qui se passe durant cette période. Supposons que vous ayez un événement tous les jours à la même heure et, puisque vous êtes basé aux États-Unis, vous allez ajuster les heures en utilisant l'heure d'été américaine.

Day (2001)   United States   Europe      United Kingdom   Global    Time delta
March 5th    EST 1500        CET  2100   GMT 2000         GMT 2000        +23h
March 6th    EDT 1500        CET  2000   GMT 1900         GMT 1900        +24h
March 7th    EDT 1500        CET  2000   GMT 1900         GMT 1900        +24h
..............................................................................
March 26th   EDT 1500        CET  2000   GMT 1900         GMT 1900        +24h
March 27th   EDT 1500        CEST 2100   BST 2000         GMT 1900        +24h

Analysons toutes les possibilités:

• Si vous affichez l'heure dans un fuseau horaire mondial et que vous l'appelez UTC , ce qui semble être la bonne chose à faire, vous allez confondre vos clients américains, qui vont voir différentes heures UTC (hier 20h, aujourd'hui 19h) pour le même heure d'horloge murale (hier à 15 heures, aujourd'hui à 15 heures à nouveau), puis vos clients basés dans l'UE, qui ne voient pas le changement d'horloge affiché et doivent cependant changer l'heure de leur événement d'horloge murale.

• Si vous affichez l'heure dans un fuseau horaire mondial et l'appelez GMT , en plus de dérouter les clients américains, vous confondrez également les clients britanniques qui passent de GMT à BST. Il est contre-intuitif de comprendre que EDT 1500 et EST 1400 sont le même moment dans le temps; traduisez maintenant cela en BST / GMT (avec le problème supplémentaire que vous n'allez pas afficher les heures BST dans aucune partie du site).

• Si vous affichez le fuseau horaire dans un fuseau horaire de l'UE (j'ai utilisé CET / CEST pour éviter la confusion GMT / UTC), cela va évidemment être très déroutant pour vos clients américains, qui voient l'heure de l'événement basculer d'avant en arrière deux fois et pourtant sans aucun mur le temps de l'horloge se change. Alors que vos clients américains peuvent être prêts pour le premier interrupteur (après tout, ils doivent changer leurs horloges murales le même jour), ils seront surpris par ce dernier.

• Si vous affichez le fuseau horaire dans le fuseau horaire américain (comme EST / EDT ), vous aurez la situation exacte expliquée ci-dessus, mais en miroir!

Cela semble être une situation désespérée! Voici comment j'en suis venu à y remédier après quatre ans passés à travers ce rigolade (deux fois par an, évidemment): "inventer un fuseau horaire".

Je suis exactement dans la situation illustrée ci-dessus, j'ai donc composé "NYT" (fuseau horaire de New York) afin que je puisse écrire "1500 NYT" pour signifier "15 heures dans le fuseau horaire que New York utilise."

Cela a l'avantage que, tant que l'utilisateur sait que la valse DST se produit, il a un moyen très simple de faire des allers-retours dans leur propre fuseau horaire: google " time in new york " pour voir quelle heure il est à NY , puis travaillez à partir de là. Vous pouvez même avoir de la fantaisie et utiliser des services basés sur la géolocalisation tels que time.is/15:00_in_New_York .

Notez que, bien que vous puissiez utiliser les noms d'abréviations de fuseau horaire dans time.is, je vous exhorte à ne pas le faire, car ils sont assez confus à ce sujet eux-mêmes: EST a le même temps que EDT‽

Vous pouvez informer les utilisateurs de l'heure d'été avec une courte description, en vous connectant à un service Web de conversion de temps approprié pour aider les gens. Idéalement, tous les horodatages devraient avoir une option à convertir en heure locale.

En fin de compte, vous devez vous rendre compte que j'ai ignoré l'éléphant dans la pièce depuis longtemps, et c'est la solution de "compte à rebours" que vous avez déjà mise en œuvre. Il n'y a rien de confus à propos de "en 1 jour 2 heures 45 minutes 47 secondes" (et si vous croyez que vous n'avez pas besoin de beaucoup de précision, vous voudrez peut-être réfléchir à nouveau ).

Bien sûr, selon mon expérience, je n'ai jamais eu le luxe de quoi que ce soit qui ne soit pas du texte statique, j'ai donc dû gérer l'incroyable désordre illustré ci-dessus (et ce n'est que le début ! , mais pour votre cas d'utilisation, cela ressemble à la solution avec le moins de risque de confusion. Vous pouvez obtenir deux fils de discussion par an sur les événements «en 23 heures» et «en 25 heures» alors que le compte à rebours commence normalement par «en 24 heures», mais c'est tout.