. .net serializator JSON zwraca czas lokalnego klienta do przeglądarki?

Question

Używam asp.net [WebMethod] do wypychania obiektu .net z powrotem do wywołania Ajax w przeglądarce. Jedną z właściwości obiektu jest typ DateTime.

Po dostarczeniu do przeglądarki, czas wynosi siedem godzin przed godziną przechowywaną na serwerze SQL.
OK, więc moja przeglądarka jest w Peru (GMT-5), a serwer jest w Niemczech (obecnie GMT + 2), stąd 7 godzin.

jako poprawka wyślę przesunięcie UTC na kliencie z żądaniem Ajax

d = new Date(); 
d.getTimezoneOffset(); 

następnie na serwerze I dowiedzieć się przesunięcie tam:

// get a local time zone info 
    TimeZoneInfo tz = TimeZoneInfo.Local; 

    // get it in hours 
    int offset = tz.BaseUtcOffset.Hours; 

    // add one hour if we are in daylight savings 
    if (tz.IsDaylightSavingTime(DateTime.Now)) 
    { 
     offset++; 
    } 

Teraz mogę ustalić czas pole w moim obiekcie, zanim zostanie wysłane do przeglądarki.

Moje prawdziwe pytanie brzmi: w jaki sposób serialser wie o 7 godzinach?

Żądanie http nie zawiera żadnych informacji o czasie.

Czy za dużo pytam, czy chcę dokładny czas przechowywany w bazie danych?

Aktualizacja:

Oto przykład, data w bazie danych: 2009-Oct-15 22:00

Nie ma strefy czasowej przywiązany do tego.

Kiedy zadzwonić do WebMethod na moim komputerze dev, gdzie klient i serwer są oczywiście w tej samej strefie czasowej, JSON z serwera jest:

{"d":{"TheDate":"\/Date(1255662000000)\/"}} 

JSON ze zdalnego serwera w Niemczech:

{"d":{"TheDate":"\/Date(1255636800000)\/"}} 

jest to różnica w ciągu 7 godzin w JSON jak widać na Firebug'a. W tym punkcie nie ma jeszcze JavaScript.

Jedną z moich pomysłów było to, że asp.net dołącza strefę czasową do sesji, ale wydaje się, że tak nie jest.

Answer 1

Aby odpowiedzieć na pytanie, ops, informacja czasowa jest ukryte w konwersji do JSON/Date()/format, bo to jest w stosunku do UTC. Na przykład na moim serwerze tutaj w NY, jeśli zwrócę DateTime.Parse ("1/1/1970"), to zwraca/Data (18000000) /, lub, 5 godzin (jesteśmy teraz w DST), które jest to liczba sekund od 1/1/1970 UTC, ponieważ konwersja mówi, „hej, to 1.01.1970 00:00:00 tutaj w NY, więc musi być 1/1/70 05:00 : 00 z powrotem w Greenwich. "

Teraz, jeśli klient w Kalifornii otrzymał tę datę zapisu i po prostu tworzy datę JavaScript z milisekund (np. Nowa data (18000000)), przeglądarka powie: "hej, tutaj jest obiekt daty, który ja wiem, że jest w stosunku do UTC i wiem, że jestem 8 godzin od Greenwich, więc musi to być 12/31/1969 21:00:00. "

Jest to bardzo sprytny sposób radzenia sobie z czasem, dzięki czemu jest "poprawny" we wszystkich strefach czasowych i taki, że cała lokalizacja jest obsługiwana przez przeglądarkę użytkownika. Niestety, często mamy do czynienia tylko z nieprzetworzoną datą, w której nie chcemy być względni (np. Urodziny). Jeśli potrzebujemy zachować tę samą datę, istnieją dwa sposoby, które znam.

Po pierwsze, tak jak w powyższym przykładzie, należy dostosować czas (chociaż uważam, że należy to zrobić również w przeglądarce, jeśli chcesz, aby działał w dowolnej strefie czasowej).

Innym sposobem byłoby zwrócić go jako ciąg, już sformatowany. Jest to metoda, którą normalnie stosuję, ale zwykle pracuję z klientami z USA (mogę na przykład zwrócić MM/DD/YYYY i nie wściekają się na mnie za bycie Amerykaninem).

Answer 2

Aby uniknąć dziwnych błędów i mieć do czynienia z tego typu problemami, zawsze powinieneś radzić sobie z UTC i konwertować na czas lokalny w ostatnim możliwym momencie.

W jaki sposób badasz DateTime, gdy pojawi się w przeglądarce? Czy na pewno w surowym serializowanym formacie nie uwzględniono przesunięcia w ramach obiektu DateTime? W takim przypadku może odtworzyć na drugim końcu w czasie lokalnym

Answer 3

Po prostu wpadłem na ten sam problem. Wygląda na to, że Json Serializer zwraca daty w domyślnej strefie czasowej, w której znajduje się system (zasadniczo pomijając strefę czasową, w której znajduje się DateTime).

np.: Na moim komputerze dev zwraca daty w strefie czasowej, w której znajduje się moja maszyna (Pacific); na naszej maszynie produkcyjnej daty JSON są w UTC - która jest strefą czasową, na którą ustawiony jest serwer.

Aby rozwiązać ten problem, w naszym przypadku musieliśmy ręcznie dodać hoursoffset, czas minutesoffset i letniego przesunięcie w kliencie poprzez javascript.