2010-01-20 14 views
8

GWT nie porządkuje poprawnie daty Java. Kiedy próbowałem wysłać Datę utworzoną w Javascript przez przewód, dowiedziałem się, że daty od 1 kwietnia (zabawne) do 25 października na lata przed rokiem 1983 są odejmowane o jeden dzień.GWT java.util.Date błąd serializacji

Oznacza to, że, powiedzmy, zarówno 1982-04-01, jak i 1982-03-31 stają się 1982-03-31 po stronie Java.

Biorąc pod uwagę daty, przypuszczam, że jest to jakiś problem z DST. Próbowałem googling i znalazłem tylko one other reference, który opisuje podobny problem.

Próbowałem również zgłosić błąd do zespołu GWT, ale z ciekawością nie udało się znaleźć błędu dla GWT.

Więc moje pytania to:

  1. Każdy inny bieg do tego? Jestem na GWT 1.7 i chciałbym potwierdzić, czy to się dzieje również w wersji 2.0.

  2. Moje obejście polegało na wysyłaniu dat jako ciągów i analizowaniu ich na serwerze. Ktoś wie lepiej?

+1

Napotkaliśmy inne problemy związane z datą (nie wiemy już, co to było), więc przełączyliśmy się na Ciągi. – Drejc

Odpowiedz

5

Zakładając, że używasz java.util.Date

Pytanie 1: Wydaje się, że jest ona ustalana w 2,0. Stworzyłem obie daty powyżej (1982-04-01 i 1982-03-31) i trafiają poprawnie do serwera (oba reprezentują na serwerze odpowiednio 1982-04-01 i 1982-03-31). Moja konfiguracja to:

  • GWT 2.0
  • Java 1.6
  • OSX 10.6.2

Pytanie 2: Zawsze możesz przejść do „milisekund od 1 stycznia 1970, 00:00:00 GMT "nad usługą asynchroniczną - którą można uzyskać za pomocą metody getTime() w obiekcie daty. Po stronie serwera można następnie utworzyć nową datę przekazującą tę wartość do konstruktora:
Date date = new Date(millis);
Pozwala to zaoszczędzić na manipulowaniu przy użyciu formaterów i analizatorów składni.

+1

W rzeczywistości GWT już serializuje za pomocą milisekund, ale opuszcza strefę czasową. Tak więc "3. kwietnia 2001 00:00 GMT" w przeglądarce może stać się "2. kwietnia 2001 23:00 CET" na serwerze. A jeśli spojrzysz tylko na datę, która wydaje się być dniem wolnym od pracy, mimo że faktyczny czas oznacza to samo. – Stroboskop

0

Mamy również podobny problem. To było wystarczająco dawno temu, że nie pamiętam dokładnych szczegółów, ale istniały pewne drobne różnice między java.util.Date a sposobem obsługi dat w JavaScript. Nasze obejście było faktycznie takie samo, jak twoje, gdzie rzeczywista wartość wysłana przez przewód była generalnie ciągiem.

1

Jeśli nie musisz przeprowadzać konwersji po stronie klienta (dostosuj do strefy czasowej użytkownika) lub obliczeń, wyślij ją w ciągu znaków z serwera.

Jednak nigdy nie natknęliśmy się na konkretny problem.

2

Daty i godziny są skomplikowanym tematem. Konwersja może być zależna od ustawień narodowych, w których działa przeglądarka, a ponadto zarówno wirtualna maszyna JVM na serwerze, jak i ustawienia lokalne klientów są aktualne.

W niektórych przypadkach mogą występować różnice, ponieważ w niektórych regionach w przeszłości przełączano strefy czasowe.

GWT wysyła daty za pomocą zaledwie milis od czasu epoki.Ponieważ używa obiektów Date, użytkownik ma ograniczone możliwości, że daty po stronie serwera zostaną automatycznie zmodyfikowane do strefy czasowej serwerów. Czy jesteś pewien, że bierzesz pod uwagę możliwą różnicę w strefach czasowych między klientem a serwerem?

David

+0

W moim przypadku serwer i klient pracowały na tym samym komputerze, więc jest to z pewnością problem z serializacją GWT. – Domchi

+0

Może w tym samym oknie TERAZ. Ale patrząc na daty, myślę, że właśnie odkryłeś czas letni. I jedna z maszyn/usług nie bierze tego pod uwagę przy serializacji czasu. I niezależnie od tego - nie sądzę, że chcesz zrobić usługę internetową, która zależy od strefy czasowej przeglądarki jest taka sama jak serwer. – Stroboskop

1

Ewentualne problemy Soure jest różnica w strefach czasowych klient/serwer.

+0

Zobacz moją odpowiedź na David, klient i serwer są w tej samej strefie czasowej. Uważam, że problem polega na tym, że obsługa JavaScript i Java odbywa się w różny sposób, więc wysyłanie milisekund nie jest wystarczająco dobre. – Domchi

Powiązane problemy