Come devo gestire gli Fusi orari in un'applicazione WCF .NET?

Naviga le tue risposte
6

La nostra azienda gestisce un'applicazione SaaS in cui gli utenti effettuano l'accesso da tutto il mondo (anche se principalmente negli Stati Uniti). Memorizziamo tutte le informazioni relative al nostro tempo come UTC, ma abbiamo bisogno di visualizzare gli orari usando l'ora locale. L'applicazione è basata sul Web e vorremmo "rilevare automaticamente" il fuso orario dell'utente utilizzando javascript per determinare le loro correzioni UTC durante i vari periodi dell'anno. Le informazioni sull'offset dell'utente verranno passate al nostro server nella prima richiesta e il server cercherà tutti gli Fusi orari di cui è a conoscenza e vedrà quali fusi orari validi corrispondono.

Mi piacerebbe utilizzare l'oggetto TimeZoneInfo integrato, ma capisco che 

TimeZoneInfo.GetSystemTimeZones();

si basa sulle impostazioni del registro del server. Al momento disponiamo di 18 server Web con bilanciamento del carico che ospitano il nostro livello di servizio WCF, e I credo il nostro team di TechOps è attento a garantire che tutti i server vengano corretti con lo stesso service pack in qualsiasi momento.

Devo anche prestare particolare attenzione ai vari Fusi orari degli Stati Uniti, in particolare Pacifico, Montagna, Centrale e Orientale. Posso supporre che il campo ID basato su stringhe non cambi presto? Ad esempio, se chiamo 

TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time")

Voglio che venga restituito l'oggetto TimeZoneInfo appropriato.

Quindi alcune domande:

  • Qual è il modo migliore per gestire i fusi orari, soprattutto quando si tratta delle regole che cambiano (le regole del fuso orario degli Stati Uniti sono state modificate nel 2006) e la determinazione degli offset. Dovrei provare qualcos'altro? Tieni presente che il team del prodotto non vuole che l'utente debba selezionare il proprio fuso orario e che stia bene con i fusi orari che vengono segnalati in modo impreciso in determinate condizioni (ad es. Se l'utente è in Messico, va bene riportarlo come " Pacific Standard Time "invece del più accurato" Pacific Standard Time (Messico) ".
  • Se presumo che tutti i server Web con carico bilanciato eseguano sempre la stessa versione del sistema operativo e il livello di patch, posso presumere che otterrò risultati coerenti?
  • Ci sono altre cose che devo prendere in considerazione?
posta JackAce 20.08.2012 - 21:12
fonte

2 risposte

4

Penso che tu sia sulla strada giusta usando la classe TimeZoneInfo integrata. L'ID non dovrebbe mai cambiare, ma il nome sarà (ho imparato quella lezione nel modo più duro quando diversi sono cambiati tra xp e vista). Ho usato un approccio praticamente identico (UTC solo al servizio e livelli db, ora locale sul server web e client) e ha funzionato bene.

Una cosa che suggerisco è di racchiudere i vari metodi TimeZoneInfo che intendi utilizzare con un'interfaccia ITimeZoneConverter o qualcosa di quella natura, in questo modo se hai bisogno di cambiare la tua implementazione in un secondo momento, dovrebbe essere più facile da fare.

Disturbo casuale: la classe .Net TimeZoneInfo non può darti un'abbreviazione data un fuso orario. IE: No "EST" per "Eastern Standard Time", quindi se hai bisogno di questo, pianifica di avere una ricerca in qualche sorta di file di risorse o tabella per quello.

Javascript non sarà in grado di dirti il fuso orario, ma solo l'offset del fuso orario da UTC. È una differenza sottile, e nel tuo caso sembra che non abbia importanza, ma è qualcosa da tenere a mente quando guardi quali timezone vengono assegnati ai tuoi utenti.

Ho visto alcune librerie JS come questa che tentano di indovinare il fuso orario il lato client in base a fuso orario offset e più popolati. È un approccio interessante, ma non so quanto bene funzionerebbe nella produzione.

Infine, una cosa che mi ha morso in passato era che JSON in realtà non specificava nulla su come formattare i datetime. ( lettura correlata ) Se stai facendo molte richieste ajax / async e intendiamo convertire avanti e indietro tra utc e amp; tempi locali, questo può essere doloroso. Assicurati di scrivere alcune funzioni comuni di parsing / offset e assicurati che tutti i membri del tuo team ne siano a conoscenza e non reinventano la ruota ogni volta che si occupano di questi problemi.

    
risposta data 20.08.2012 - 21:24
fonte
1

Un'altra cosa da considerare: c'è una differenza tra xST e xDT; per esempio, l'Arizona è MST, cioè non aderiscono all'ora legale, quindi in modo efficace sono in montagna durante l'inverno e il Pacifico durante l'estate.

    
risposta data 23.08.2012 - 20:40
fonte

Leggi altre domande sui tag

Come posso impedire agli utenti di unire origine / X a Y in git? Come negoziare con i fornitori di software che non rispettano gli standard HL7 [chiuso]