DateTime vs DateTimeOffset

DateTimeOffset jest reprezentacją czasu chwilowego (znanego również jako czasu absolutnego ). Przez to, mam na myśli moment w czasie, który jest uniwersalny dla wszystkich (nie licząc sekund przestępnych, lub relatywistycznych efektów dylatacji czasu). Innym sposobem reprezentacji czasu chwilowego jest DateTime Gdzie .Kind jest DateTimeKind.Utc.

Różni się to od czasu kalendarza (znanego również jako czasu cywilnego ), który jest pozycją na czyjejś kalendarz, i istnieje wiele różnych kalendarzy na całym świecie. Nazywamy te kalendarze strefami czasowymi . Czas kalendarzowy jest reprezentowany przez DateTime Gdzie .Kind to DateTimeKind.Unspecified, lub DateTimeKind.Local. I .Local ma znaczenie tylko w scenariuszach, w których masz dorozumiane zrozumienie, gdzie znajduje się komputer, który korzysta z wyniku. (Na przykład stacja robocza użytkownika)

Więc dlaczego DateTimeOffset zamiast UTC DateTime? chodzi o perspektywę. użyjmy analogii - będziemy udawać fotografów.

Wyobraź sobie, że stoisz na osi czasu kalendarza, wskazując kamerę na osobę na chwilowej osi czasu ułożonej przed tobą. Ustawiasz aparat zgodnie z zasadami strefy czasowej - które zmieniają się okresowo ze względu na czas letni lub inne zmiany prawnej definicji strefy czasowej. (Nie masz stabilnej ręki, więc twój aparat się trzęsie.)

Osoba stojąca na zdjęciu widzi kąt z którego pochodzi Twoja kamera. Gdyby inni robili zdjęcia, mogliby być pod różnymi kątami. To właśnie reprezentuje Offset część DateTimeOffset.

Więc jeśli oznaczasz swój aparat "czas Wschodni", czasami wskazujesz od -5, a czasami wskazujesz od -4. Są kamery na całym świecie, wszystkie oznaczone różnymi rzeczami, i wszystkie wskazujące na tę samą chwilową oś czasu z różnych kątów. Niektóre z nich są tuż obok (lub na) siebie, więc po prostu znajomość przesunięcia nie wystarczy, aby określić, z którą strefą czasową jest związany.

A co z UTC? Cóż, to jedyna kamera, która ma gwarancję, że będzie miała stałą rękę. Jest na statywie, mocno zakotwiczony w ziemi. Nigdzie się nie wybiera. Jego kąt widzenia nazywamy przesunięciem zerowym.

Więc - co ta analogia nam mówi? Zawiera kilka intuicyjnych wytycznych.

• Jeśli reprezentujesz czas względny do jakiegoś miejsca w szczególności, reprezentować go w czasie kalendarzowym za pomocą DateTime. Tylko upewnij się, że nigdy nie pomylisz jednego kalendarza z innym. To powinno być twoje założenie. Local jest użyteczny tylko z DateTime.Now. Na przykład, mogę uzyskać DateTime.Now i zapisać go w bazie danych - ale kiedy go odzyskam, muszę założyć, że jest to Unspecified. Nie mogę polegać na tym, że mój lokalny kalendarz jest tym samym kalendarzem, z którego został pierwotnie wzięty.

• Jeśli zawsze musisz być pewny chwili, upewnij się, że reprezentujesz chwilowy czas. Użyj DateTimeOffset, aby go wymusić, lub użyj UTC DateTime zgodnie z konwencją.

• Jeśli chcesz śledzić chwilę chwilowego czasu, ale chcesz również wiedzieć "o której godzinie użytkownik myślał, że jest w swoim lokalnym kalendarzu?"- wtedy musisz użyć DateTimeOffset. Jest to bardzo ważne na przykład w przypadku systemów pomiaru czasu - zarówno w kwestiach technicznych, jak i prawnych.

• Jeśli kiedykolwiek będziesz musiał zmodyfikować wcześniej nagrany DateTimeOffset - nie masz wystarczającej ilości informacji w samym offsecie, aby upewnić się, że nowy offset jest nadal odpowiedni dla użytkownika. Musisz również zapisać identyfikator strefy czasowej (pomyśl - potrzebuję nazwy tego aparatu, aby móc zrobić nowe zdjęcie, nawet jeśli pozycja się zmieniła).

  Należy również zwrócić uwagę, że czas Noda ma do tego celu reprezentację o nazwie ZonedDateTime, podczas gdy Biblioteka klas bazowych. Net nie ma niczego podobnego. Musisz przechowywać zarówno DateTimeOffset i TimeZoneInfo.Id wartość.

• Czasami będziesz chciał reprezentować czas kalendarzowy, który jest lokalny dla "każdego, kto na niego patrzy". Na przykład, definiując co dzisiaj oznacza. Dziś jest zawsze od północy do północy, ale reprezentują one niemal nieskończoną liczbę nakładających się zakresów na chwilowej osi czasu. (W praktyce mamy skończoną liczbę stref czasowych, ale można wyrazić przesunięcia aż do kleszcza), więc w takich sytuacjach upewnij się, że rozumiesz, jak albo ograniczyć " kto pyta?"pytanie w dół do jednej strefy czasowej, lub radzić sobie z tłumaczeniem ich z powrotem do czasu chwilowego, stosownie do potrzeb.

Oto kilka innych drobiazgów na temat DateTimeOffset, które wspierają tę analogię, i kilka wskazówek, jak utrzymać ją prosto: {]}

• Jeśli porównasz dwie wartości DateTimeOffset, są one najpierw znormalizowane do zerowego przesunięcia przed porównaniem. Innymi słowy, 2012-01-01T00:00:00+00:00 i 2012-01-01T02:00:00+02:00 odnoszą się do tej samej chwili i dlatego są odpowiednik.

• Jeśli wykonujesz jakieś testy jednostkowe i musisz być pewien offsetu, przetestuj zarówno wartość DateTimeOffset, jak i właściwość .Offset oddzielnie.

• Istnieje jednokierunkowa ukryta konwersja wbudowana w. Net framework, która pozwala przekazać DateTime do dowolnego parametru lub zmiennej DateTimeOffset. Kiedy to robimy, .Kind ma znaczenie . Jeśli zdasz Typ UTC, będzie on przenoszony z zerowym przesunięciem, ale jeśli zdasz .Local lub .Unspecified, będzie Załóżmy, że jest lokalny . Framework w zasadzie mówi: "Cóż, poprosiłeś mnie o konwersję czasu kalendarza na chwilowy czas, ale nie mam pojęcia, skąd to się wzięło, więc po prostu użyję lokalnego kalendarza."To jest ogromna gotcha, jeśli załadujesz nieokreślony DateTime na komputer z inną strefą czasową. (IMHO-to powinno rzucić wyjątek-ale nie.)

Wtyczka Bezwstydna:

Wiele osób podzieliło się ze mną, że znajdują ta analogia jest niezwykle cenna, więc włączyłem ją do mojego kursu Pluralsight, podstawy daty i czasu . Krok po kroku zapoznasz się z analogią kamery w drugim module, "context Matters", w klipie zatytułowanym"czas kalendarzowy a czas Chwilowy".