Qual è il fuso orario corretto per visualizzare gli orari degli eventi online?

Il mio sito web ha regolarmente eventi programmati dall'utente. Al momento stiamo utilizzando il nostro fuso orario EDT (o EST) come fuso orario di base per tutti gli eventi sul sito. Sento che questo è 1) sbagliato o 2) molto confuso. Attualmente, abbiamo utenti in tutti gli Stati Uniti e in Europa.

Il metodo corretto per localizzare gli orari si basa sul fuso orario dei clienti? usare UTC / GMT?

Grazie

Onestamente, questo è un problema che si vede spesso quando si utilizza un sito Web da più fusi orari. C'è una lunga lista di modi per superare la battaglia. Per riassumere Badp, ci sono molti fattori che contribuiscono al modo in cui vengono elaborati i diversi fusi orari.

La maggior parte dei siti Web sceglie una delle due diverse soluzioni per risolvere questo problema:

1) Memorizza qualsiasi cosa che coinvolga una data come UTC nel database ... e consenti a un'impostazione definita dall'utente per gli utenti sul tuo sito Web di scegliere in quale fuso orario si trovano ... o fare qualche magia di ricerca geo-ip per scoprirlo dove sono nel mondo e trovare il fuso orario appropriato ... e poi ogni volta che visualizzi la data ... assicurati di chiamare qualunque funzione necessaria per la localizzazione. Quasi ogni linguaggio di programmazione ha un metodo per visualizzare le date utilizzando un fuso orario specificato. Dovresti anche farlo al contrario per gli utenti che inseriscono le date. (prendere l'ora locale e riconvertire in UTC per l'archiviazione DB) Questo è probabilmente l'approccio più comune. Ciò consentirebbe anche di risparmiare un sacco di tempo dal tentativo di "reinventare la ruota". Per quanto riguarda i visitatori anonimi ... è possibile A) attenersi a EST / EDT (utilizzando le chiamate di funzione integrate per la visualizzazione appropriata) o B) ripristinare la ricerca Geo-IP e selezionare un fuso orario basato su un'ipotesi istruita. È anche una buona idea specificare sempre il fuso orario in cui stai visualizzando la data / ora. Ad esempio, non dire mai "12:00" ... assicurati che sia "12:00 EDT"

oppure 2) Segui il modello di stackexchange (e molti altri) per visualizzare la differenza tra ora e quando il post è stato creato. cioè invece di "pubblicato su x date" ... faresti "x hours ago" o "x days x hours ago" ecc ... o per date future ... "tra 6 giorni 14 ore ..." Questo sta rapidamente diventando più comune in molte situazioni ... ma non è l'ideale per le pianificazioni di tipo calendario.

Ovviamente ... puoi ancora adottare una sorta di ibrido tra i due ... e potresti dover fare un passo ulteriore e memorizzare le date come utc ... ma anche memorizzare un fuso orario specifico per un evento. Alla fine, la decisione è tua.

Ecco il problema: l'UE e gli Stati Uniti non attivano e disattivano l'ora legale contemporaneamente; questo marzo, c'è stata una differenza di tre settimane tra questi eventi.

Ecco cosa succede durante questo periodo. Supponiamo che tu abbia un evento ogni giorno alla stessa ora e, dal momento che risiedi negli Stati Uniti, regolerai gli orari utilizzando l'ora legale degli Stati Uniti.

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

Analizziamo tutte le possibilità:

• Se visualizzi l'ora in un fuso orario globale e lo chiami UTC , che sembra la cosa giusta da fare, confonderai i tuoi clienti americani, che vedranno orari UTC diversi (ieri 8pm, oggi 7pm) per il stesso orario dell'orologio a muro (ieri alle 15:00, di nuovo oggi alle 15:00), quindi i tuoi clienti con sede nell'UE, che non vedono il cambio dell'orologio pubblicato e che devono comunque cambiare l'orario dell'evento dell'orologio a muro.

• Se visualizzi l'ora in un fuso orario globale e lo chiami GMT , oltre a confondere i clienti statunitensi, confonderai anche i clienti del Regno Unito che passano da GMT a BST. È controintuitivo capire che EDT 1500 e EST 1400 sono lo stesso momento nel tempo; ora traducilo in BST / GMT (con l'ulteriore problema che non mostrerai i tempi BST in nessuna parte del sito).

• Se visualizzi il fuso orario in un fuso orario dell'UE (ho usato CET / CEST per evitare confusione GMT / UTC), sarà ovviamente molto confuso per i tuoi clienti statunitensi, che vedono l'ora dell'evento passare avanti e indietro due volte e tuttavia non sperimentano alcun muro l'orologio cambia se stessi. Mentre i tuoi clienti statunitensi potrebbero essere pronti al primo passaggio (dopo tutto devono cambiare gli orologi da parete lo stesso giorno), saranno sorpresi da quest'ultimo.

• Se visualizzi il fuso orario nel fuso orario degli Stati Uniti (come EST / EDT ), avrai la situazione esatta spiegata sopra, ma rispecchiata!

Sembra una situazione senza speranza! Ecco come sono arrivato ad affrontarlo dopo quattro anni passati attraverso questo rigmarole (due volte l'anno, ovviamente): "inventare un fuso orario".

Sono esattamente nella situazione nella foto sopra, quindi ho inventato "NYT" (New York Timezone) in modo da poter scrivere "1500 NYT" per significare "15:00 in qualunque fuso orario sia New York."

Questo ha il vantaggio che, fintanto che l'utente sa che si sta verificando il valzer dell'ora legale, ha un modo molto semplice di convertire avanti e indietro nel proprio fuso orario: google " time in new york " per vedere che ore sono a New York , quindi risolvilo da lì. Puoi anche divertirti e utilizzare i servizi basati sulla geolocalizzazione come time.is/15:00_in_New_York .

Si noti che, mentre si potrebbe utilizzare nomi abbreviazione di fuso orario in time.is, vi esorto di non farlo, perché sono abbastanza confusi su tutto se stessi: EST ha lo stesso tempo come EDT ‽

Puoi informare gli utenti dell'ora legale con un po 'di disturbo, collegandoti a un servizio web di conversione del tempo appropriato per aiutare le persone. Idealmente, tutti i timestamp dovrebbero avere un'opzione da convertire in ora locale.

Quando tutto è stato detto e fatto, dovresti capire che ho ignorato l'elefante nella stanza per tutto il tempo, e questa è la soluzione "conto alla rovescia" che hai già implementato. Non c'è nulla di confuso nel "in 1 giorno 2 ore 45 minuti 47 secondi" (e se ritieni di non aver bisogno di tanta precisione potresti voler ripensarci ).

Certo, nella mia esperienza non ho mai avuto il lusso di nulla che non fosse un testo statico, quindi ho dovuto gestire l'incredibile confusione nella foto sopra (e questo è solo l' inizio ! Che ne dici dell'emisfero meridionale, che fa l'ora legale all'indietro?) , ma per il tuo caso d'uso sembra la soluzione con il minimo potenziale di confusione. Potresti ricevere due discussioni all'anno che chiedono informazioni sugli eventi "in 23 ore" e "in 25 ore" mentre di solito conta alla rovescia da "in 24 ore", ma il gioco è fatto.