Pytanie Identyfikacja stref czasowych w ISO 8601


Nie, nie mówię o przesunięciach stref --- te mogą się zmieniać w ciągu roku dla regionu opartego na np. DST. Mówię o tym, co rzeczywiste strefy czasowe utrzymywane przez IANA. Rozumiem, że tak nie obsługiwane przez ISO 8601, prawda?

Co robią platformy, aby wspierać identyfikację stref czasowych w reprezentacjach łańcuchów podobnych do ISO 8601? Zauważyłem, że najnowsza biblioteka daty / czasu Java używa do tego rozszerzonego formatu ISO 8601, np. 2011-12-03T10:15:30+01:00[Europe/Paris]. (Widzieć DateTimeFormatter API.)

Czy istnieje jakaś konwencja zbieżna (na przykład z innymi językami i platformami) w celu rozszerzenia ISO 8601 w celu obsługi oznaczenia strefy czasowej?


14
2018-02-12 23:37


pochodzenie


Drugi punkt wypunktowania sprawia, że ​​pytanie to jest dość szerokie. - chrylis
Sposób, w jaki czytam opis W3Cwydaje się, że masz rację: ISO 8601 obsługuje przesunięcia stref, ale nie strefy czasowe ze zmiennymi przesunięciami (zazwyczaj strefy czasowe z czasem letnim, które dotyczą wielu stref czasowych IANA). - Ole V.V.
@ OleV.V. Wiązany dokument W3C Note jest jedynie krótkim streszczeniem aktualnego standardu ISO 8601. Sugeruję przeczytanie tego, co doskonałe Artykuł Wikipedii o ISO 8601 i dalej data tygodniai być może projekt normy (oficjalny standard znajduje się za zaporą). - Basil Bourque
Chcę tylko zauważyć, że jestem zdumiony, że w chwili, gdy wygasa ta nagroda, wszyscy ci ludzie i wszystkie te komentarze mogą wymyślić tylko jeden inny przykład biblioteki / platformy (@MattJohnson wspomniał o czasie węzła), który zawiera strefę czasową w formacie smyczkowym! - Garret Wilson


Odpowiedzi:


Rozumiem, że nie są one obsługiwane przez ISO 8601, prawda?

Poprawny. ISO-8601 nie zajmuje się identyfikatorami stref czasowych. Nazwy TZ IANA / Olson nie są "standardem". Są po prostu najbardziej niezawodną rzeczą, jaką mamy. (Niektórzy mogą uznać je za de facto standard.)

Co platformy robią, aby to wspierać?

Co dokładnie wspierasz? Ta część twojego pytania jest niejasna. Jeśli chcesz wspierać strefy czasowe IANA, to wszystko jest wszędzie. Niektóre platformy mają je wbudowane, a niektóre opierają się na bibliotekach. Jeśli chcesz obsługiwać ciąg znaków reprezentujący identyfikator ISO-8601 data-time-offset + strefa czasowa ID, niektóre platformy mają to, a inne nie. Będziesz musiał być bardziej szczegółowy, jeśli chcesz wiedzieć więcej.

Zauważyłem, że najnowsza biblioteka daty / czasu Java używa do tego rozszerzonego formatu ISO 8601, np. 2011-12-03T10: 15: 30 + 01: 00 [Europa / Paryż]. (Zobacz interfejs API DateTimeFormatter.)

Myślę, że mówisz DateTimeFormatter.ISO_ZONED_DATE_TIME. Dokumenty mówią konkretnie:

ISO-lubić formater daty i czasu ...

... rozszerza rozszerzony format daty i czasu ISO-8601, aby dodać strefę czasową. Sekcja w nawiasach kwadratowych nie jest częścią normy ISO-8601.

Jest to specyficzny format Java, a nie standard.

Czy istnieje jakaś konwencja zbieżna (na przykład z innymi językami i platformami) w celu rozszerzenia ISO 8601 w celu obsługi oznaczenia strefy czasowej?

O ile mi wiadomo, obecnie nie ma standardu, który obejmowałby łączenie znacznika czasu ISO8601 z identyfikatorem strefy czasowej IANA w jeden format. Można go reprezentować na wiele różnych sposobów, w tym:

  • 2011-12-03T10:15:30+01:00[Europe/Paris]  (jest to ustawienie domyślne w Javie 8)
  • 2011-12-03T10:15:30+01:00(Europe/Paris)
  • 2011-12-03T10:15:30+01:00 Europe/Paris
  • 2011-12-03T10:15:30+01:00 - Europe/Paris
  • 2011-12-03T10:15:30+01:00/Europe/Paris
  • 2011-12-03T10:15:30+01:00|Europe/Paris
  • 2011-12-03T10:15:30 Europe/Paris (+01)    (jest to domyślne w czasie Noda)

Jeśli to, czego szukasz, jest sposobem na dodanie ZonedDateTime lub podobne dane w API w znormalizowany sposób, moją osobistą rekomendacją byłoby przekazanie nazwy strefy czasowej w osobnym polu. W ten sposób każda porcja danych jest tak dobra, jak tylko może być. Na przykład w JSON:

{
  "timestamp": "2011-12-03T10:15:30+01:00",
  "timezone": "Europe/Paris"
}

13
2018-02-13 03:53



Co ciekawe, również Dokumentacja Java ZonedDateTime u góry użyj formatu z separatorem przestrzeni zamiast nawiasami. ;) - Matt Johnson
"Wsparcie co dokładnie? Ta część twojego pytania jest niejasna." Cóż, pomyślałem, że umieściłem to w tytule ... Ale wystarczy - zaktualizowałem to pytanie. "Jeśli chcesz obsługiwać łańcuchową reprezentację identyfikatora ISO-8601 daty i godziny-przesunięcia + strefy czasowej, niektóre platformy to mają, a inne nie." Cóż, to jest pytanie, które zadaję. Co robią inne platformy? Miałem nadzieję, że ktoś mógłby podać mi kilka innych przykładów, więc mogłem się dowiedzieć, czy Java jest na tym samym poziomie, czy też podąża za jakimś zbiegającym się trendem. - Garret Wilson
Wygląda na to, że szukasz RFC. Być może powinieneś go zaproponować? :) - Matt Johnson
Hej, właśnie to odkryłem istnieje szkic dla ISO8601-2 "extentions" w pracach na ISOi oczywiście od razu pomyślałem o tobie. Być może możesz skontaktować się z nimi, aby zasugerować włączenie tego? :) - Matt Johnson
FYI - Zacząłem wątek na Twitterze tutaj, jeśli chcesz zadzwonić. :) - Matt Johnson


The Odpowiedz przez Matt Johnson jest poprawne. Dodam tylko kilka myśli.

Strefa czasowa versus offset-from-UTC

Na offset-from-UTC to tylko kilka godzin, minut i sekund w przód / tył UTC. To samo czyni datę i godzinę w określonym momencie na osi czasu. Ale nie jest to aż tak pouczające, jak włączenie oficjalna nazwa strefy czasowej także.

Chociaż nie ma jeszcze standardu do włączenia nazwy strefy czasowej, mam nadzieję, że inni podążają na czele klas java.time dodając w nawiasach kwadratowych nazwę strefy czasowej. Ten format wydaje mi się rozsądny, ponieważ byłoby łatwo obcinać część wspornika kwadratowego, aby była kompatybilna wstecz z niezrozumiałym oprogramowaniem.

Na przykład:
2011-12-03T10:15:30+01:00[Europe/Paris]. Jeśli dane były tylko 2011-12-03T10:15:30+01:00, bylibyśmy w stanie określić moment na osi czasu, ale nie bylibyśmy w stanie dopasować innych momentów do tego samego poziomu umysłu, ponieważ nie wiedzielibyśmy, jakie zasady regulacji zastosować. Strefy takie jak Europe/Zagreb, Africa/Brazzaville, Arctic/Longyearbyen, i Europe/Isle_of_Man wszystkie mają udział w offsecie +01:00, ale mogą również obowiązywać inne regulacje różniące się od tych obowiązujących Europe/Paris. Więc jeśli spróbujesz dodać trzy dni do wartości 2011-12-03T10:15:30+01:00, naprawdę nie możesz wiarygodnie obliczyć wyniku, ponieważ nie wiesz, jakie dostosowania mogą być konieczne, np. przecięcia czasu letniego, które mogą wystąpić w ciągu tych trzech dni.

Strefa czasowa określa zestaw reguł dotyczących obsługi anomalii, takich jak Czas letni (DST). Politycy na całym świecie lubią wprowadzać poprawki w swoich strefach czasowych, a nawet zmieniać je. Zasady te często się zmieniają. Pomyśl o strefie czasowej jako zbiorze przesunięć w czasie, wielu okresach w historii, w których każdy okres miał szczególne przesunięcie w użyciu w tym konkretnym regionie.

Strefę czasową można traktować jako zbiór wartości przesunięcia z UTC. W America/Los_Angeles część tego roku jest 8 godzin za UTC, a część roku będzie 7 godzin za UTC. W ten sposób zbierane są 2 punkty danych w ramach tej strefy czasowej.

Inny przykład, w poprzednich latach, Turcja spędzała część każdego roku 2 godziny przed UTC i część każdego roku 3 godziny naprzód. W 2016 r. Zmieniono to na czas nieokreślony, pozostając 3 godziny naprzód. Tak wiele punktów danych w strefie czasowej Europe/Istanbul.

Po prostu użyj UTC

Osobiście nie widzę dużej wartości nawet przy użyciu takich wartości jak 2011-12-03T10:15:30+01:00. Bez strefy czasowej równie dobrze możesz użyć samego UTC. W tym przypadku, 2011-12-03T09:15:30Z (9 rano zamiast 10 rano).

Ogólnie najlepszą praktyką jest wykorzystanie UTC podczas przechowywania i wymiany wartości daty i godziny. Pomyśl o UTC jako o czasie rzeczywistym, z wartościami strefowymi lub offsetowymi będącymi zwykłymi odmianami.


10
2018-02-13 06:23



Zasadniczo zgadzam się z poradą dotyczącą używania UTC, jeśli to możliwe. Niektóre przypadki użycia są jednak niezręczne: jeśli logika musi odnosić się do dowolnego zdarzenia w przeszłości lub przyszłości, dla którego jedyną informacją o czasie jest strefa lokalna, konwersja UTC nie jest oczywista. (Na przykład, o której godzinie NYSE zostanie otwarte w drugi wtorek marca, za 10 lat? W czasie lokalnym najprawdopodobniej jest to 9:30 czasu wschodniego, ale UTC zależy od konwersji czasu letniego - i to nawet zależy od przepisów nie zmieniając się wcześniej.) W takich przypadkach lepiej byłoby mieć standard reprezentowania czasów strefowych. - sumitsu
@Sumitsu Zgadzam się całkowicie, 100%. Podkreślam przeciwne stanowisko, ponieważ uważam, że programiści mają tendencję do (a) napędzania się orzechami zmieniającymi się we własnej parafialnej strefie czasowej i (b) myślą (modlą się), że używają "lokalnych" (niezamówionych) wartości daty i godziny w jakiś sposób uwolni ich od zajmowania się problemami strefy czasowej. Ale jak mówisz, LocalDateTime jest z pewnością przydatna w wielu sytuacjach, w szczególności w apelach takich jak otwarcie NYSE, ponieważ politycy tak często, tak niedbale i tak szybko redefiniują strefy czasowe. Na przykład w zeszłym roku Turcja zdecydowała się pozostać w DST z ostrzeżeniem tylko przez kilka tygodni. - Basil Bourque
Tylko TZ-offset pozwala na zbieranie trochę wartość względna klienta. Chociaż nie jest tak wytrzymały jak nazwy TZ do innych celów, to zapewnia mały krok. Głównie (w 99% przypadków w czas nagrywania) pozwalając "dzień" w odróżnieniu od czasu podczas przechwytywania zarówno w "pojedynczym skalar". Przesunięcie TZ ma ładną właściwość nad nazwą TZ, ponieważ jest czystym odwzorowaniem na UTC, chociaż jest w stanie również przechwyć nazwę TZ w takiej "pojedynczej skalarnej" formie, byłoby miło, aby umożliwić przyszłą poprawioną obsługę:} - user2864740
..i czysta koncepcja "dnia" jest często pomijana z podejściami czasu UTC. Jednak dla wielu aspektów życia wszystko, co jest istotne, to dzień i względny czas. W tym wspólnym kontekście nie ma znaczenia, czy ten dzień przeskoczy do przodu i powróci z "czasu rzeczywistego" przez rok (y). - user2864740