Pytanie Dzienne wskazówki dotyczące czasu i strefy czasowej [zamknięte]


Mam nadzieję, że sprawię, że to pytanie i odpowiedzi na nie będą ostatecznym wskazówką, jak radzić sobie z czasem letnim, w szczególności w odniesieniu do faktycznych zmian.

Jeśli masz coś do dodania, proszę

Wiele systemów jest zależnych od zachowania dokładnego czasu, problem polega na zmianie czasu z powodu oszczędności światła dziennego - przesunięcie zegara do przodu lub do tyłu.

Na przykład, jeden ma reguły biznesowe w systemie przyjmującym zamówienia, które zależą od czasu zamówienia - jeśli zegar się zmieni, reguły mogą nie być tak jasne. Jak powinien utrzymywać się czas zamówienia? Istnieje oczywiście nieskończona liczba scenariuszy - ta jest po prostu ilustracyjna.

  • Jak poradziłeś sobie z problemami z oświetleniem dziennym?
  • Jakie założenia są częścią twojego rozwiązania? (szukam tutaj kontekstu)

Ważne, jeśli nie bardziej:

  • Czego próbowałeś, to nie zadziałało?
  • Dlaczego to nie zadziałało?

Byłbym zainteresowany programowaniem, systemem operacyjnym, utrwalaniem danych i innymi istotnymi aspektami tego problemu.

Ogólne odpowiedzi są świetne, ale chciałbym zobaczyć szczegóły, szczególnie jeśli są one dostępne tylko na jednej platformie.


1886


pochodzenie


@abatishchev - W ten sposób GETDATE() na SQL będzie UTC (jak będzie DateTime.Now). A serwer nie zostanie zrealizowany przez żadne automatyczne zmiany czasu letniego. - Oded
@Oded: Mogę się zgodzić, jeśli "na serwerze" zostanie dodany. Ale nadal może to wpłynąć na inne aplikacje, które wymagają czasu lokalnego. Z tego i innych powodów uważam, że lepiej poprosić o czas Utc. - abatishchev
UTC jest preferowane względem GMT, zarówno ze względu na bardziej precyzyjne zdefiniowanie, jak i dlatego, że definicje GMT są pomieszane w niektórych systemach operacyjnych. Ludzie często traktują terminy "GMT" i "UTC" jako wymienne, ale nie do końca. W prawie każdym celu oprogramowania / systemów użyj UTC. Widzieć stackoverflow.com/questions/2292334/... - Chris Johnson
@JoshStodola - Jon Skeet's 'odpowiedź". - Kenny Evitt
@Naprawiono, że nie można założyć, że serwer będzie na UTC, widziałem serwery produkcyjne, w których strefa czasowa była "UTC", ale zastosowano DST, więc w rzeczywistości było to UTC + 1 przez ponad pół roku. Zgadzam się z @abatishchev, aby był wyraźny i używał DateTime.UtcNow i GETUTCDATE(), pokazuje też innym programistom, że tak naprawdę o tym pomyślałeś - ono2012


Odpowiedzi:



Podsumowanie odpowiedzi i innych danych: (proszę dodać swoje)

Zrobić:

  • Ilekroć odnosisz się do dokładnego momentu w czasie, utrzymuj ten czas zgodnie ze zunifikowanym standardem, na który nie wpływają zmiany w ciągu dnia. (GMT i UTC są równoważne pod tym względem, ale preferowane jest użycie terminu UTC. Zulus lub Z czas.)
  • Jeśli zamiast tego zdecydujesz się na utrzymywanie czasu za pomocą wartości czasu lokalnego, uwzględnij lokalne przesunięcie czasowe dla tego określonego czasu z UTC (przesunięcie to może się zmienić w ciągu roku), tak że znacznik czasu może być później interpretowany jednoznacznie.
  • W niektórych przypadkach może być konieczne zapisanie obie czas UTC i równoważny czas lokalny. Często odbywa się to za pomocą dwóch oddzielnych pól, ale niektóre platformy obsługują datetimeoffset typ, który można przechowywać zarówno w jednym polu.
  • Podczas zapisywania znaczników czasu jako wartości liczbowej użyj Czas Unix - od tego to liczba pełnych sekund 1970-01-01T00:00:00Z (z wyłączeniem sekund przestępnych). Jeśli potrzebujesz większej precyzji, zamiast tego użyj milisekund. Ta wartość powinna zawsze być oparta na UTC, bez żadnej korekty strefy czasowej.
  • Jeśli możesz później zmienić znacznik czasu, dołącz oryginalny identyfikator strefy czasowej, aby określić, czy przesunięcie mogło się zmienić od pierwotnie zapisanej wartości.
  • Podczas planowania przyszłych zdarzeń zazwyczaj preferowany jest czas lokalny zamiast UTC, ponieważ często zmienia się przesunięcie. Zobacz odpowiedź, i post na blogu.
  • Przechowując całe daty, takie jak urodziny i rocznice, nie konwertuj na UTC lub inną strefę czasową.
    • Jeśli to możliwe, przechowuj dane w typie daty, który nie obejmuje pory dnia.
    • Jeśli taki typ nie jest dostępny, pamiętaj, aby zawsze zignorować porę dnia podczas interpretowania wartości. Jeśli nie możesz być pewny, że pora dnia zostanie zignorowana, wybierz 12:00 w południe, zamiast 00:00 północy jako bardziej bezpieczny czas reprezentatywny tego dnia.
  • Pamiętaj, że przesunięcia stref czasowych nie zawsze są liczbą całkowitą godzin (na przykład indyjski standardowy czas to UTC + 05: 30, a Nepal - UTC + 05: 45).
  • Jeśli używasz Javy, użyj java.time dla języka Java 8 lub użyj Czas na Jodę dla Java 7 lub niższej.
  • Jeśli używasz .NETTO, rozważ użycie Noda Time.
  • Jeśli używasz .NET bez Noda Time, rozważ to DateTimeOffset jest często lepszym wyborem niż DateTime.
  • Jeśli używasz Perla, użyj DateTime.
  • Jeśli korzystasz z Pythona, użyj pytz lub dateutil.
  • Jeśli używasz JavaScript, użyj moment.js z moment-strefa czasowa rozbudowa.
  • Jeśli używasz PHP> 5.2, użyj natywnych konwersji stref czasowych dostarczonych przez DateTime, i DateTimeZone klasy. Zachowaj ostrożność podczas używania DateTimeZone::listAbbreviations() - Zobacz odpowiedź. Aby zachować PHP z aktualnymi danymi Olson, instaluj je okresowo timezonedb Pakiet PECL; Zobacz odpowiedź.
  • Jeśli używasz C ++, upewnij się, że używasz biblioteki, która używa poprawnie implementuje Baza danych stref czasowych IANA. Obejmują one cctz, ICU, i Biblioteka "tz" Howarda Hinnanta.
    • Nie używaj Podnieść do konwersji stref czasowych. Podczas jego API twierdzi, że obsługuje standardowe identyfikatory IANA (inaczej "zoneinfo") z grubsza je odwzorowuję do danych POSIX-owych, bez uwzględnienia bogatej historii zmian, jakie mogła mieć każda strefa. (Ponadto plik został usunięty z konserwacji).
  • Większość reguł biznesowych używa czasu urzędowego, a nie UTC lub GMT. Dlatego przed zastosowaniem logiki aplikacji zaplanuj konwersję znaczników UTC na lokalną strefę czasową.
  • Pamiętaj, że strefy czasowe i przesunięcia nie są stałe i mogą ulec zmianie. Na przykład historycznie USA i Wielka Brytania używały tych samych terminów do "wiosny naprzód" i "powrotu". Jednak w 2007 roku Stany Zjednoczone zmieniły daty wymiany zegarów. Oznacza to, że przez 48 tygodni w roku różnica między czasem londyńskim a nowojorskim wynosi 5 godzin, a przez 4 tygodnie (3 na wiosnę, 1 na jesieni) 4 godziny. Pamiętaj o takich elementach w obliczeniach obejmujących wiele stref.
  • Rozważ typ czasu (rzeczywisty czas zdarzenia, czas rozgłoszenia, czas względny, czas historyczny, czas powtarzania), które elementy (znacznik czasu, przesunięcie strefy czasowej i nazwa strefy czasowej) musisz zapisać w celu poprawnego wyszukiwania - patrz "Typy czasu" w ta odpowiedź.
  • Zachowaj synchronizację plików tzdata systemu operacyjnego, bazy danych i aplikacji między sobą a resztą świata.
  • Na serwerach ustaw zegary sprzętowe i zegary systemu operacyjnego na UTC, a nie lokalną strefę czasową.
  • Niezależnie od poprzedniego punktu, kod po stronie serwera, w tym strony internetowe, powinien nigdy oczekiwać, że lokalna strefa czasowa serwera będzie czymś szczególnym. Zobacz odpowiedź.
  • Wolaj pracować ze strefami czasowymi indywidualnie dla każdego przypadku w kodzie aplikacji, a nie globalnie, poprzez ustawienia pliku konfiguracyjnego lub ustawienia domyślne.
  • Posługiwać się NTP usługi na wszystkich serwerach.
  • Jeśli używasz FAT32, pamiętaj, że znaczniki czasu są przechowywane w czasie lokalnym, a nie w UTC.
  • W przypadku powtarzających się wydarzeń (np. Cotygodniowy program telewizyjny) pamiętaj, że czas zmienia się wraz z czasem letnim i będzie różny w różnych strefach czasowych.
  • Zawsze wyszukuj wartości daty i czasu jako dolna granica włącznie, górna granica wyłączna (>=, <).

Nie:

  • Nie mylić "strefy czasowej", takiej jak America/New_York z "przesunięciem strefy czasowej", takim jak -05:00. To są dwie różne rzeczy. Widzieć wiki tagów strefy czasowej.
  • Nie używaj JavaScript Date obiekt do wykonywania obliczeń daty i godziny w starszych przeglądarkach internetowych, tak jak w ECMAScript 5.1 i starszych wada projektowa może nieprawidłowo wykorzystywać czas letni. (Zostało to naprawione w ECMAScript 6/2015).
  • Nigdy nie ufaj zegarowi klienta. To może być źle.
  • Nie mów ludziom, aby "zawsze używali UTC wszędzie". Ta szeroka opinia jest krótkowzroczna z kilku ważnych scenariuszy opisanych wcześniej w tym dokumencie. Zamiast tego użyj odpowiedniego czasu dla danych, z którymi pracujesz. (Znacznik czasowy może korzystać z UTC, ale nie powinno to być przyszłe harmonogramy i wartości tylko dla daty.)

Testowanie:

  • Podczas testowania upewnij się, że testujesz kraje w krajach zachodnich, wschodnich, północnych i Południowy półkule (w rzeczywistości w każdym kwartale globu, czyli 4 regiony), z obu DST w toku, a nie (daje 8), oraz kraj, który nie używa DST (kolejne 4 obejmuje wszystkie regiony, co daje łącznie 12).
  • Przetestuj przejście DST, tj. Gdy jesteś w okresie letnim, wybierz wartość czasu z zimy.
  • Testuj przypadki graniczne, takie jak strefa czasowa, która jest UTC + 12, z DST, określając czas lokalny UTC + 13 w lecie, a nawet w zimie UTC + 13
  • Przetestuj wszystkie biblioteki i aplikacje innych firm i upewnij się, że poprawnie obsługują dane strefy czasowej.
  • Sprawdź co najmniej półgodzinne strefy czasowe.

Odniesienie:

Inny:

  • Lobby swojego przedstawiciela, aby zakończyć obrzydliwość, która jest DST. Zawsze możemy mieć nadzieję ...
  • Lobby dla Czas standardowy Ziemi

803



Używanie GMT naprawdę nie rozwiązuje problemu, nadal musisz się dowiedzieć co to właściwa delta do zastosowania i tu leży cała złożoność. Delta może być skomplikowana do określenia w systemach używanych przez użytkowników w różnych regionach (z różnymi harmonogramami przełączania dziennego) lub w systemach z danymi historycznymi / przyszłymi. - ckarras
To prawda, jeśli wszystkie aplikacje muszą wyświetlać bieżący czas lokalny. Ale jeśli mamy na przykład serwer w Australii, który musi wyświetlać datę / godzinę transakcji w Kanadzie w dniu 2 kwietnia 2006 r. (Był to ostatni rok przed zmianą zasad zmiany czasu letniego w Kanadzie) - czy masz połączenie z systemem operacyjnym? to może zrobić DateTime ("2006/04/02 14: 35Z"). ToLocalTime (). WithDaylightSavingRules ("Canada", 2006)? - ckarras
Tak, istnieje takie wywołanie systemu operacyjnego w Windows - SystemTimeToTzSpecificLocation. msdn.microsoft.com/en-us/library/ms724949(VS.85).aspx - Michael Madsen
@tchrist Może, jeśli jesteś wytrwały, możesz. - Peter Ajtai
Pamiętaj o przekształcaniu przyszłych dat (nawet jutro) w UTC zawsze stracić coś. Na przykład użyłeś jakiegoś znanego przesunięcia, aby dokonać tej konwersji, ale ponieważ data jest w przyszłości, zawsze jest szansa, że ​​grupa, która ustawi te reguły, zmieni te reguły. Niemożliwe jest również przekształcenie niektórych przyszłych dat w UTC, ponieważ czasy letnie nie są znane przed upływem tego roku (niektóre kraje ustalają daty każdego roku, a nie 10 lat wcześniej lub w oparciu o ustalone zasady). - eselk


Nie jestem pewien, co mogę dodać do powyższych odpowiedzi, ale oto kilka punktów ode mnie:

Rodzaje czasów

Są cztery różne czasy, które powinieneś rozważyć:

  1. Event time: np. Czas, w którym rozgrywa się międzynarodowe wydarzenie sportowe lub koronacja / śmierć / itp. Jest to zależne od strefy czasowej zdarzenia, a nie od przeglądarki.
  2. Czas telewizji: np. Określony program telewizyjny jest emitowany o godzinie 21:00 czasu lokalnego na całym świecie. Ważne, gdy myślisz o opublikowaniu wyników (np. American Idol) w swojej witrynie
  3. Względny czas: np .: pytanie to ma otwarte zamknięcie nagród w ciągu 21 godzin. Jest to łatwe do wyświetlenia
  4. Czas powtarzalny: np .: Program telewizyjny jest dostępny w każdy poniedziałek o godzinie 21:00, nawet po zmianie czasu letniego.

Istnieje również czas historyczny / alternatywny. Są irytujące, ponieważ mogą nie odwzorowywać z powrotem do standardowego czasu. Np .: daty juliańskie, daty według kalendarza księżycowego na Saturnie, kalendarz Klingonów.

Przechowywanie znaczników czasu rozpoczęcia / zakończenia w UTC działa dobrze. Dla 1 potrzebujesz nazwy strefy czasowej zdarzenia + przesunięcia zapisanych wraz ze zdarzeniem. W przypadku 2 musisz mieć lokalny identyfikator czasu przechowywany w każdym regionie i lokalną nazwę strefy czasowej + przesunięcie zapisane dla każdego przeglądarki (możliwe jest wyprowadzenie tego z adresu IP, jeśli jesteś w kryzysie). Dla 3, przechowuj w UTC sekundach i nie potrzebujesz stref czasowych. 4 to szczególny przypadek 1 lub 2 w zależności od tego, czy jest to zdarzenie globalne, czy lokalne, ale musisz także zapisać plik utworzone w znacznik czasu, aby można było sprawdzić, czy definicja strefy czasowej została zmieniona przed lub po utworzeniu tego wydarzenia. Jest to konieczne, jeśli chcesz wyświetlić historyczne dane.

Czas przechowywania

  • Zawsze przechowuj czas w UTC
  • Konwertuj na czas lokalny na ekranie (lokalny jest definiowany przez użytkownika przeglądającego dane)
  • Przechowując strefę czasową, potrzebujesz nazwy, znacznika czasu i przesunięcia. Jest to wymagane, ponieważ rządy czasami zmieniają znaczenie swoich stref czasowych (np. Rząd USA zmieniał daty DST), a aplikacja musi radzić sobie z wdzięcznością ... np .: dokładny znacznik czasu, gdy odcinki LOST pokazywały się zarówno przed, jak i po DST zmienione.

Przesunięcia i nazwy

Przykładem powyższego może być:

Finał mistrzostw świata w piłce nożnej   wydarzyło się w RPA (UTC + 2 - SAST)   11 lipca 2010 o godzinie 19:00 UTC.

Dzięki tym informacjom możemy historycznie ustalić dokładny czas finałów WCS 2010, nawet jeśli zmieni się definicja strefy czasowej w RPA, i być w stanie wyświetlić to dla widzów w ich lokalnej strefie czasowej w momencie, gdy wysyłają zapytania do bazy danych.

Czas systemu

Musisz również zsynchronizować pliki tzata systemu operacyjnego, bazy danych i aplikacji, zarówno ze sobą, jak iz resztą świata, i intensywnie testować po aktualizacji. Nie jest niespotykane, że aplikacja innej firmy, od której jesteś zależny, nie poprawiła poprawnie zmiany TZ.

Upewnij się, że zegary sprzętowe są ustawione na UTC, a jeśli korzystasz z serwerów na całym świecie, upewnij się, że ich systemy są skonfigurowane do używania również UTC. Staje się to oczywiste, gdy trzeba kopiować co godzinę obrócone pliki dziennika serwera apache z serwerów w wielu strefach czasowych. Sortowanie według nazwy pliku działa tylko wtedy, gdy wszystkie pliki mają nazwy o tej samej strefie czasowej. Oznacza to również, że nie musisz robić daty matematyki w głowie, kiedy ssh z jednego pola do drugiego i trzeba porównywać znaczniki czasu.

Uruchom także ntpd we wszystkich polach.

Klienci

Nigdy nie ufaj, że znacznik czasu otrzymany z komputera klienta jest ważny. Na przykład nagłówki Date: HTTP lub javascript Date.getTime() połączenie. Są one w porządku, gdy są używane jako nieprzejrzyste identyfikatory lub podczas wykonywania matematyki z datą podczas pojedynczej sesji na tym samym kliencie, ale nie próbuj łączyć tych wartości z czymś, co masz na serwerze. Twoi klienci nie używają NTP i niekoniecznie muszą mieć działającą baterię dla swojego zegara BIOS.

Drobnostki

W końcu rządy czasami robią bardzo dziwne rzeczy:

Standardowy czas w Holandii był   dokładnie 19 minut i 32,13 sekundy   przed prawem UTC z mocy prawa z 1909-05-01   do 1937-06-30. Ta strefa czasowa   nie można dokładnie przedstawić za pomocą   format HH: MM.

Ok, chyba już koniec.


288



Ta odpowiedź ma kilka świetnych punktów, szczególnie chciałem wskazać tę część "Czas powtarzalny: np.: Program telewizyjny jest w każdy poniedziałek o 21.00, nawet gdy czas letni się zmienia" Przechowywanie czasów w UTC w DB, a następnie konwersja dla wyświetlania pomaga w obsłudze wiele trudnych aspektów radzenia sobie ze strefami czasowymi. Jednak obsługa "powtarzających się zdarzeń" przekraczających bariery DST staje się znacznie trudniejsza. - Jared Hales
+1 dla ciekawostek. Utrzymywanie treści interesujących sprawia, że ​​to zadanie jest przyjemniejsze, co może prowadzić do zwiększenia wydajności :) - Chris
Wiele dobrych rzeczy w tej odpowiedzi, ale kilka problemów. 1) Wiele skrótów strefy czasowej jest niejednoznacznych. Spójrz tutaj  2) Nie zawsze czy chcesz przechowywać w UTC. Przez większość czasu - tak, ale kontekst ma znaczenie. W twoich warunkach czas telewizji nie będą przechowywane w UTC. Ponadto, czasami jest to niezgodne z prawem lub niezgodne z polityką, aby nie przechowywać czasu lokalnego - czyli takich rzeczy DateTimeOffset (lub odpowiednik) są przydatne. W przeciwnym razie, dobrze napisać. - Matt Johnson
Holenderskie ciekawostki wyglądają legalnie. ietf.org/rfc/rfc3339.txt sekcja 5.8. W połowie zrozumiałem, że ktoś ciągnie za nogę. - ruffin
Kolejny przykład dla rządów do robienia dziwnych rzeczy: timeanddate.com/news/time/turkey-scraps-dst-2016.html - Ad Infinitum


Jest to ważny i zaskakująco trudny problem. Prawda jest taka, że ​​nie istnieje całkowicie satysfakcjonujący standard utrzymywania czasu. Na przykład standard SQL i format ISO (ISO 8601) są niewystarczające.

Z konceptualnego punktu widzenia zwykle mamy do czynienia z dwoma typami danych z datą-godziną i wygodnie je rozróżniać (powyższe standardy nie): "czas fizyczny" i "czas obywatelski".

"Fizyczna" chwila czasu jest punktem w ciągłej uniwersalnej linii czasu, którą zajmuje się fizyka (oczywiście ignorując względność). Ta koncepcja może być odpowiednio zakodowana - na przykład w UTC, (jeśli zignorujesz sekundy przestępne).

Czas "cywilny" jest specyfikacją datetime, która jest zgodna z normami cywilnymi: punkt czasu jest tutaj w pełni określony przez zestaw pól datetime (Y, M, D, H, MM, S, FS) plus TZ (specyfikacja strefy czasowej) (również "kalendarz", faktycznie, ale pozwala zakładać, że ograniczamy dyskusję do kalendarza gregoriańskiego). Strefa czasowa i kalendarz wspólnie pozwalają (w zasadzie) mapować z jednej reprezentacji na drugą. Ale cywilne i fizyczne momenty czasu są zasadniczo różnymi typami wielkości i powinny być utrzymywane koncepcyjnie oddzielone i traktowane inaczej (analogia: tablice bajtów i ciągi znaków).

Kwestia ta jest myląca, ponieważ mówimy o tych typach wydarzeń zamiennie i dlatego, że czasy cywilne podlegają zmianom politycznym. Problem (i potrzeba rozróżnienia tych pojęć) staje się bardziej widoczny w przypadku wydarzeń w przyszłości. Przykład (wzięty z mojej dyskusji tutaj.

John zapisuje w swoim kalendarzu przypomnienie o zdarzeniu w datetime 2019-Jul-27, 10:30:00, TZ =Chile/Santiago, (które zrównoważyło GMT-4, stąd odpowiada UTC 2019-Jul-27 14:30:00). Ale pewnego dnia w przyszłości kraj postanawia zmienić przesunięcie TZ na GMT-5.

Teraz, kiedy nadejdzie ten dzień ... jeśli to przypomnienie będzie wyzwalać

ZA) 2019-Jul-27 10:30:00 Chile/Santiago  = UTC time 2019-Jul-27 15:30:00 ?

lub

B) 2019-Jul-27 9:30:00 Chile/Santiago  = UTC time 2019-Jul-27 14:30:00 ?

Nie ma poprawnej odpowiedzi, chyba że ktoś wie, co John miał na myśli kiedy powiedział w kalendarzu "Proszę, zadzwoń do mnie 2019-Jul-27, 10:30:00 TZ=Chile/Santiago".

Czy miał na myśli "cywilną datę i godzinę" ("kiedy zegary w moim mieście mówią 10:30 ")? W takim przypadku A) jest poprawną odpowiedzią.

Czy może miał na myśli "fizyczną chwilę czasu", punkt w continuusie linia czasu naszego wszechświata, powiedzmy: "kiedy następne zaćmienie Słońca się dzieje. "W takim przypadku odpowiedź B) jest poprawna.

Kilka interfejsów API Data / Czas uzyskuje to rozróżnienie: pośród nich Jodobime, która jest podstawą następnego (trzeciego!) API Java DateTime (JSR 310).


81



Inną kwestią do rozważenia, której nie spotkałem w przypadku interfejsów API, jest to, że nawet gdy podano strefę czasową i czasową, istnieją co najmniej dwa wiarygodne znaczenia dla np. "13: 00: 00EDT". Można by to odnieść do czegoś, o czym wiadomo, że miało miejsce o godzinie 13 czasu lokalnego, co do którego przypuszczano, że było Wschodnim Dniem Światła, lub czegoś, o czym wiadomo, że miało miejsce w momencie, gdy czas wschodni uderzył o 13:00, co jest uważane za miały miejsce w miejscu obserwującym czas wschodniego słońca. Jeśli masz wiele znaczników czasu, w których informacje o strefie czasowej mogą być nieprawidłowe (na przykład pliki z aparatu cyfrowego) ... - supercat
... wiedza na temat tego, czy odzwierciedlają dokładny czas lokalny lub czas globalny, może być ważna w określaniu sposobu ich korygowania. - supercat
Najwyraźniej John chce A), ponieważ ludzie idą do pracy o 8:30, niezależnie od czasu letniego czy strefy czasowej. Jeśli wejdą do DST, pójdą do pracy o 8:30, kiedy wyjdą z DST, pójdą do pracy o 8:30. Jeśli kraj zdecyduje się przejść do innej strefy czasowej, zacznie działać o godzinie 8:30 każdego dnia - Gianluca Ghettini


Wyraźnie rozdzielić wątpliwości - dokładnie wiedzieć, które warstwy wchodzą w interakcje z użytkownikami i zmienić datę i godzinę na / z reprezentacji kanonicznej (UTC). Data i godzina inna niż UTC to prezentacja (podąża za lokalną strefą czasową użytkowników), Czas UTC jest modelem (pozostaje unikalny dla back-end i mid tiers).

Również, zdecyduj, jaka jest twoja aktualna publiczność, czego nie musisz podawać i gdzie narysujesz linię. Nie dotykaj egzotycznych kalendarzy, chyba że masz tam ważnych klientów, a następnie rozważ oddzielne serwery skierowane do użytkowników tylko dla tego regionu.

Jeśli możesz zdobyć i utrzymać lokalizację użytkownika, użyj lokalizacji dla systematycznej konwersji daty i godziny (powiedzmy .NET culture lub tabeli SQL), ale zapewnij użytkownikowi możliwość wyboru przesłonięć, jeśli data i godzina są kluczowe dla użytkowników.

Jeśli istnieją historyczne obowiązki audytu zaangażowany (jak dokładnie mówiąc, kiedy Jo w AZ zapłacił rachunek 2 lata temu we wrześniu) następnie zachowaj zarówno czas UTC, jak i czas lokalny dla rekordu (twoje tabele konwersji zmienią się z biegiem czasu).

Określ czasową referencyjną strefę czasową dla danych, które są przesyłane zbiorczo - podobne pliki, serwisy internetowe itp. Powiedz, że firma East Coast ma centrum danych w CA - musisz zapytać i wiedzieć, czego używają jako standard zamiast przyjmować jedno lub drugie.

Nie ufaj przesunięciom stref czasowych osadzonym w tekstowej reprezentacji daty i godziny nie akceptuj parsowania i podążaj za nimi. Zamiast tego zawsze żądaj wyraźnego zdefiniowania strefy czasowej i / lub strefy odniesienia. Możesz łatwo otrzymać czas z przesunięciem PST, ale czas jest rzeczywiście EST, ponieważ jest to czas odniesienia klienta i rekordy były eksportowane tylko na serwerze, który jest w PST.


53





Musisz wiedzieć o Olsonie Baza danych tz, który jest dostępny od ftp://elsie.nci.nih.gov/pub  http://iana.org/time-zones/. Jest aktualizowany wiele razy w roku, aby poradzić sobie z często ostatnimi minutami zmian w czasie (i czy) przełączania pomiędzy zimą i latem (czas standardowy i letni) w różnych krajach na całym świecie. W 2009 roku ostatnia wersja to 2009; w 2010 r. był to rok 2010n; w 2011 r. był to 2011n; pod koniec maja 2012 r. wydano wersję 2012c. Zauważ, że istnieje zestaw kodów do zarządzania danymi i rzeczywistymi danymi strefy czasowej w dwóch osobnych archiwach (tzcode20xxy.tar.gz i tzdata20xxy.tar.gz). Zarówno kod, jak i dane są własnością publiczną.

Jest to źródło nazw stref czasowych, takich jak America / Los_Angeles (i synonimy, takie jak US / Pacific).

Jeśli chcesz śledzić różne strefy, potrzebujesz bazy danych Olson. Jak radzili inni, chcesz również przechowywać dane w ustalonym formacie - zwykle jest to UTC - wraz z zapisem strefy czasowej, w której dane zostały wygenerowane. Możesz chcieć odróżnić przesunięcie od czasu UTC w danym czasie do nazwy strefy czasowej; to może zrobić różnicę później. Ponadto, wiedząc, że jest to obecnie 2010-03-28T23: 47: 00-07: 00 (US / Pacific) może lub nie może pomóc w interpretacji wartości 2010-11-15T12: 30 - co jest prawdopodobnie określone w PST ( Pacific Standard Time) zamiast PDT (Pacific Daylight Saving Time).

Standardowe interfejsy biblioteki C nie są strasznie pomocne w tego typu sprawach.


Dane Olsona uległy przeniesieniu, po części dlatego, że A D Olson wkrótce przejdzie na emeryturę, a częściowo dlatego, że w związku z naruszeniem praw autorskich wystąpił (teraz odwołany) pozew przeciwko opiekunom. Baza danych strefy czasowej jest teraz zarządzana pod auspicjami IANA, Internet Assigned Numbers Authority, a na stronie głównej znajduje się link do "Baza danych strefy czasowej". Lista dyskusyjna dyskusyjna jest teraz tz@iana.org; lista ogłoszeń jest tz-announce@iana.org.


38



Baza danych Olson zawiera historyczny również dane, co czyni go szczególnie przydatnym do obsługi DST. Np. Wie, że wartość UTC odpowiadająca 31 marca 2000 r. W USA nie jest w DST, ale wartość UTC odpowiadająca 31 marca 2008 r. W USA. - Josh Kelley
Konsorcjum Unicode utrzymuje mapowanie między identyfikatorami strefy wolnocłowej Olsona a identyfikatorami strefy czasowej systemu Windows: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/... - Josh Kelley
Zaktualizowany link do strony Konsorcjum Unicode: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/... - Span
Gdzie można znaleźć informacje o analizie plików Olsona? Chcę skompilować go do tabeli db, ale nie mogę dowiedzieć się, jak powinienem czytać pliki - shealtiel
@gidireich: główne informacje znajdują się w danych i nie jest to łatwe do zrozumienia. Główna dokumentacja dla niego znajduje się w zic.8 strona podręcznika (lub zic.8.txt). Będziesz potrzebował tzcode2011i.tar.gz plik zamiast, lub tak samo, jak tzdata2011i.tar.gz plik, aby uzyskać te informacje. - Jonathan Leffler


Ogólnie, uwzględnia lokalne przesunięcie czasu (w tym przesunięcie czasu letniego) w przechowywanych znacznikach czasu: Sam UTC nie wystarczy, jeśli chcesz później wyświetlić znacznik czasu w jego oryginalnej strefie czasowej (i ustawienie czasu letniego).

Należy pamiętać, że przesunięcie nie zawsze jest liczbą całkowitą godzin (np. Indyjski standardowy czas to UTC + 05: 30).

Na przykład, odpowiednimi formatami są krotki (czas unixowy, przesunięcie w minutach) lub ISO 8601.


24



W przypadku wyświetlania offset jest doskonały. Jeśli chcesz dokonać zmian, przesunięcie nadal nie wystarcza. Musisz także znać strefę czasową, ponieważ nowa wartość może wymagać innego przesunięcia. - Matt Johnson


Przekroczenie granicy "czasu komputerowego" i "czasu ludzi" jest koszmarem. Głównym jest to, że nie ma żadnego standardu dla reguł dotyczących stref czasowych i czasów letnich. Kraje mogą w dowolnym momencie zmienić swoją strefę czasową i reguły DST, i robią to.

Niektóre kraje, np. Izrael, Brazylia, każdego roku decyduje, kiedy mają czas letni, więc nie można z góry wiedzieć, kiedy (jeśli) czasu letniego będzie obowiązywać. Inni mają ustalone (ish) reguły dotyczące czasu obowiązywania DST. Inne kraje nie używają DST jako całości.

Strefy czasowe nie muszą różnić się w pełni od GMT. Nepal ma wartość +5,45. Istnieją nawet strefy czasowe, które mają +13. Oznacza to, że:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

są w tym samym czasie, a 3 różne dni!

Nie ma również jasnego standardu na temat skrótów dla stref czasowych i jak zmieniają się w DST, więc kończy się to na następujących rzeczach:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

Najlepszą radą jest trzymanie się jak najdalej od lokalnych czasów i trzymanie się UTC tam, gdzie możesz. Konwertuj tylko na czas lokalny w ostatnim możliwym momencie.

Podczas testów upewnij się, że testujesz kraje na półkulach zachodniej i wschodniej, zarówno w czasie DST w toku, jak i w kraju, który nie używa DST (łącznie 6).


22



Jeśli chodzi o Izrael - jest to w połowie prawdziwe. Chociaż czas zmiany czasu letniego nie jest konkretną datą w kalendarzu juliańskim - istnieje reguła oparta na kalendarzu hebrajskim (w 2014 r. Nastąpiła zmiana). W każdym razie ogólny pomysł jest poprawny - te rzeczy mogą i zmieniają się raz na jakiś czas - Yaron U.
Ponadto AST = Atlantic Standard Time. Jeśli chodzi o "najlepszą radę", jest to w porządku jako punkt wyjścia, ale musisz przeczytać resztę tej strony i powiedzieć krótką modlitwę, a być może uda ci się to na chwilę. - DavidWalley


Dla PHP:

Klasa DateTimeZone w PHP> 5.2 już bazuje na Olson DB, o którym inni wspominają, więc jeśli robisz konwersje strefy czasowej w PHP, a nie w DB, jesteś zwolniony z pracy z (trudnymi do zrozumienia) plikami Olsona.

Jednak PHP nie jest aktualizowane tak często, jak baza danych Olson DB, więc używanie konwersji stref czasowych w PHP może pozostawić Ci nieaktualne informacje DST i wpłynąć na poprawność twoich danych. Chociaż nie oczekuje się, że zdarza się to często, może się zdarzyć, i będzie się zdarzyć, jeśli masz dużą bazę użytkowników na całym świecie.

Aby poradzić sobie z powyższym problemem, użyj pakiet timezonedb pecl, jest to funkcja aktualizacji danych strefy czasowej PHP. Zainstaluj ten pakiet tak często, jak jest on aktualizowany. (Nie jestem pewien, czy aktualizacje pakietów następują dokładnie po aktualizacjach Olsona, ale wydaje się, że są aktualizowane z częstotliwością co najmniej bardzo zbliżoną do aktualizacji Olsona.)


18





Jeśli twój projekt może to pomieścić, unikaj konwersji czasu lokalnego razem! 

Wiem, że niektórym może to zabrzmieć szaleńczo, ale pomyśl o UX: użytkownicy przetwarzają w pobliżu względne daty (dziś, wczoraj, w następny poniedziałek) szybciej niż absolutne daty (2010.09.17, piątek 17 września) na pierwszy rzut oka. A kiedy myślisz o tym więcej, dokładność stref czasowych (i czasu letniego) jest ważniejsza im bliżej jest daty now(), więc jeśli możesz wyrazić daty / daty w formacie względnym za +/- 1 lub 2 tygodnie, pozostałe daty mogą być UTC i nie będzie to zbyt ważne dla 95% użytkowników.

W ten sposób możesz przechowywać wszystkie daty w UTC i porównywać w UTC i po prostu pokazywać daty UTC użytkownika poza Twoim progiem daty relatywnej.

Może to również dotyczyć danych wprowadzanych przez użytkownika (ale ogólnie w bardziej ograniczony sposób). Wybranie z listy rozwijanej, która ma tylko {Wczoraj, Dzisiaj, Jutro, Następny Poniedziałek, Następny Czwartek} jest o wiele prostsze i łatwiejsze dla użytkownika niż wybór daty. Zbieracze dat są jednymi z najbardziej wywołujących ból składników wypełniania formularzy. Oczywiście nie będzie to działać we wszystkich przypadkach, ale można zauważyć, że wystarczy bardzo sprytny projekt, aby był bardzo mocny.


15



+1 Ciekawy pomysł. UTC może być piękną rzeczą; o) - Jon Onstott