Bardzo przepraszam, ale wszystkie dotychczasowe odpowiedzi są generalnie niepoprawne. Odpowiedź jest dość prosta, ale wymaga oddzielenia pięciu punktów:
- DATE =java.sql.Date, czyli opakowanie wokół java.util.Date, czyli liczba milisekund od epoki w strefie czasowej UTC. Więc to ma rok/miesiąc/dzień/godziny/minuty/sekundy w ustalonej strefie czasowej GMT+0 (UTC). Pamiętaj jednak, że java.sql.Date ustawia składniki czasu na zero!
- TIMESTAMP =java.sql.TimeStamp, który jest opakowującym składnikiem Date, który dodaje ułamki sekund w celu obsługi standardu SQL typu DATE. Ta klasa/typ nie jest odpowiedni ani potrzebny do tego pytania, ale w skrócie zawiera datę i godzinę.
- Baza danych przechowuje obiekty DATE zgodnie z definicją (używając czasu UTC jako przesunięcia względem Javy), ale może przetłumacz czas, jeśli jest skonfigurowany w bazie danych, na inną strefę czasową. Domyślnie większość baz danych jest ustawiona na strefę czasową serwera lokalnego, co jest bardzo złym pomysłem. Panie, panowie... ZAWSZE przechowujcie obiekty DATE w UTC. Czytaj dalej...
- Czas w JVM i strefa czasowa muszą być prawidłowe. Ponieważ obiekt Date używa czasu UTC, czy przesunięcie jest obliczane dla czasu serwera? Rozważ to z silnym zaleceniem, aby czas serwera był ustawiony na GMT+0 (UTC).
- Na koniec, gdy chcemy wyrenderować DATĘ z bazy danych (przy użyciu JSF lub czegokolwiek), powinno być ustawionym na strefę czasową GMT+0, a jeśli zostanie to zrobione od strony serwera, również ... twoje daty i godziny będą ZAWSZE spójne, referencyjne i wszystkie dobre rzeczy. Jedyne, co pozostało, to wyrenderować czas, a TO jest miejsce, w którym klient użytkownika (na przykład w przypadku aplikacji internetowej) mógłby być używane do tłumaczenia czasu GMT+0 na "lokalną" strefę czasową użytkownika.
Podsumowanie:użyj czasu UTC (GMT+0) na serwerze, w bazie danych, w obiektach Java.
DATE i TIMESTAMP różnią się z perspektywy bazy danych tylko tym, że TIMESTAMP przenosi dodatkowe ułamki sekund. Oba używają GMT+0 (domniemanych). JodaTime to preferowana platforma kalendarza, która radzi sobie z tym wszystkim, ale nie rozwiąże problemów związanych z niedopasowaniem JVM do ustawień strefy czasowej bazy danych.
Jeśli projekty aplikacji od JVM do DB nie korzystają z GMT, ze względu na czas letni, regulację zegara i wszelkiego rodzaju inne regionalne gry, które rozgrywane są na światowych zegarach lokalnych ... czasy transakcji i wszystko inne zostanie na zawsze przekrzywione , bez odniesienia, niespójne itp.
Kolejna dobra odpowiedź na temat typów danych:java.util .Data a java.sql.Date
Należy również zauważyć, że Java 8 ma aktualizacje z lepszą obsługą daty/czasu (w końcu), ale to nie naprawia, że zegar serwera, na którym działa JVM, jest w jednej strefie czasowej, a baza danych w innej. W tym momencie zawsze dzieje się tłumaczenie. W każdym dużym (inteligentnym) kliencie, z którym pracuję, strefy czasowe bazy danych i serwera JVM są właśnie z tego powodu ustawione na UTC, nawet jeśli ich operacje w dużej mierze odbywają się w innej strefie czasowej.
