JPAとHibernateを使用して日付/時刻とタイムスタンプをUTCタイムゾーンに保存する方法

JPA / Hibernateを構成して、日付/時刻をデータベースにUTC（GMT）タイムゾーンとして保存するにはどうすればよいですか？この注釈付きのJPAエンティティを考えてみます。

public class Event {
    @Id
    public int id;

    @Temporal(TemporalType.TIMESTAMP)
    public java.util.Date date;
}

日付が2008-Feb-03 9:30 am太平洋標準時（PST）の場合、2008-Feb-03 5:30 pmのUTC時刻をデータベースに保存します。同様に、データベースから日付を取得するときは、UTCとして解釈してほしい。したがって、この場合、530pmは530pm UTCです。表示されると、午前9時30分PSTとしてフォーマットされます。

Hibernate 5.2では、次の構成プロパティを使用してUTCタイムゾーンを強制できます。

<property name="hibernate.jdbc.time_zone" value="UTC"/>

詳しくは、こちらの記事をご覧ください。

私の知る限りでは、Javaアプリ全体をUTCタイムゾーンに置く必要があります（Hibernateが日付をUTCに格納するため）。そして、ものを表示するときに、希望する任意のタイムゾーンに変換する必要があります（少なくともそれを行います）こちらです）。

起動時に、次のことを行います。

TimeZone.setDefault(TimeZone.getTimeZone("Etc/UTC"));

そして、目的のタイムゾーンをDateFormatに設定します。

fmt.setTimeZone(TimeZone.getTimeZone("Europe/Budapest"))

Hibernateは（存在しないため）日付のタイムゾーン情報を認識しませんが、問題を引き起こしているのは実際にはJDBCレイヤーです。ResultSet.getTimestampまた、PreparedStatement.setTimestamp両方のドキュメントで、データベースとの間で読み書きを行うときに、デフォルトで現在のJVMタイムゾーンとの間で日付を変換すると述べています。

Hibernate 3.5 org.hibernate.type.TimestampTypeでは、これらのJDBCメソッドがローカルタイムゾーンの代わりにUTCを使用するように強制することにより、これに対するソリューションを思い付きました。

public class UtcTimestampType extends TimestampType {

    private static final long serialVersionUID = 8088663383676984635L;

    private static final TimeZone UTC = TimeZone.getTimeZone("UTC");

    @Override
    public Object get(ResultSet rs, String name) throws SQLException {
        return rs.getTimestamp(name, Calendar.getInstance(UTC));
    }

    @Override
    public void set(PreparedStatement st, Object value, int index) throws SQLException {
        Timestamp ts;
        if(value instanceof Timestamp) {
            ts = (Timestamp) value;
        } else {
            ts = new Timestamp(((java.util.Date) value).getTime());
        }
        st.setTimestamp(index, ts, Calendar.getInstance(UTC));
    }
}

TimeTypeとDateTypeを使用する場合は、それらを修正するために同じことを行う必要があります。欠点は、誰かがより一般的なオーバーライド方法を知らない限り、POJOのすべての日付フィールドのデフォルトの代わりにこれらのタイプを使用することを手動で指定する必要があることです（また、純粋なJPA互換性が失われます）。

更新：Hibernate 3.6はタイプAPIを変更しました。3.6では、これを実装するためにクラスUtcTimestampTypeDescriptorを書きました。

public class UtcTimestampTypeDescriptor extends TimestampTypeDescriptor {
    public static final UtcTimestampTypeDescriptor INSTANCE = new UtcTimestampTypeDescriptor();

    private static final TimeZone UTC = TimeZone.getTimeZone("UTC");

    public <X> ValueBinder<X> getBinder(final JavaTypeDescriptor<X> javaTypeDescriptor) {
        return new BasicBinder<X>( javaTypeDescriptor, this ) {
            @Override
            protected void doBind(PreparedStatement st, X value, int index, WrapperOptions options) throws SQLException {
                st.setTimestamp( index, javaTypeDescriptor.unwrap( value, Timestamp.class, options ), Calendar.getInstance(UTC) );
            }
        };
    }

    public <X> ValueExtractor<X> getExtractor(final JavaTypeDescriptor<X> javaTypeDescriptor) {
        return new BasicExtractor<X>( javaTypeDescriptor, this ) {
            @Override
            protected X doExtract(ResultSet rs, String name, WrapperOptions options) throws SQLException {
                return javaTypeDescriptor.wrap( rs.getTimestamp( name, Calendar.getInstance(UTC) ), options );
            }
        };
    }
}

アプリが起動したときに、TimestampTypeDescriptor.INSTANCEをUtcTimestampTypeDescriptorのインスタンスに設定すると、すべてのタイムスタンプが格納され、POJOのアノテーションを変更することなくUTCとして扱われます。[これはまだテストしていません]

Spring Boot JPAを使用して、application.propertiesファイルで以下のコードを使用します。明らかに、選択したタイムゾーンを変更できます。

spring.jpa.properties.hibernate.jdbc.time_zone = UTC

次に、エンティティクラスファイルで、

@Column
private LocalDateTime created;

Shaun Stoneのヒントに基づいて、完全にダイベストクライムに基づいており、ダイベストクライミングに回答した回答を追加します。それは一般的な問題であり、解決策は少し混乱するので、それを詳細に説明したかっただけです。

これはHibernate 4.1.4.Finalを使用していますが、3.6以降は何でも機能すると思います。

最初に、ダイベストクリムのUtcTimestampTypeDescriptorを作成します

public class UtcTimestampTypeDescriptor extends TimestampTypeDescriptor {
    public static final UtcTimestampTypeDescriptor INSTANCE = new UtcTimestampTypeDescriptor();

    private static final TimeZone UTC = TimeZone.getTimeZone("UTC");

    public <X> ValueBinder<X> getBinder(final JavaTypeDescriptor<X> javaTypeDescriptor) {
        return new BasicBinder<X>( javaTypeDescriptor, this ) {
            @Override
            protected void doBind(PreparedStatement st, X value, int index, WrapperOptions options) throws SQLException {
                st.setTimestamp( index, javaTypeDescriptor.unwrap( value, Timestamp.class, options ), Calendar.getInstance(UTC) );
            }
        };
    }

    public <X> ValueExtractor<X> getExtractor(final JavaTypeDescriptor<X> javaTypeDescriptor) {
        return new BasicExtractor<X>( javaTypeDescriptor, this ) {
            @Override
            protected X doExtract(ResultSet rs, String name, WrapperOptions options) throws SQLException {
                return javaTypeDescriptor.wrap( rs.getTimestamp( name, Calendar.getInstance(UTC) ), options );
            }
        };
    }
}

次に、スーパーコンストラクターの呼び出しでSqlTypeDescriptorとしてTimestampTypeDescriptorではなくUtcTimestampTypeDescriptorを使用するUtcTimestampTypeを作成しますが、それ以外の場合はすべてをTimestampTypeに委任します。

public class UtcTimestampType
        extends AbstractSingleColumnStandardBasicType<Date>
        implements VersionType<Date>, LiteralType<Date> {
    public static final UtcTimestampType INSTANCE = new UtcTimestampType();

    public UtcTimestampType() {
        super( UtcTimestampTypeDescriptor.INSTANCE, JdbcTimestampTypeDescriptor.INSTANCE );
    }

    public String getName() {
        return TimestampType.INSTANCE.getName();
    }

    @Override
    public String[] getRegistrationKeys() {
        return TimestampType.INSTANCE.getRegistrationKeys();
    }

    public Date next(Date current, SessionImplementor session) {
        return TimestampType.INSTANCE.next(current, session);
    }

    public Date seed(SessionImplementor session) {
        return TimestampType.INSTANCE.seed(session);
    }

    public Comparator<Date> getComparator() {
        return TimestampType.INSTANCE.getComparator();        
    }

    public String objectToSQLString(Date value, Dialect dialect) throws Exception {
        return TimestampType.INSTANCE.objectToSQLString(value, dialect);
    }

    public Date fromStringValue(String xml) throws HibernateException {
        return TimestampType.INSTANCE.fromStringValue(xml);
    }
}

最後に、Hibernate構成を初期化するときに、UtcTimestampTypeを型オーバーライドとして登録します。

configuration.registerTypeOverride(new UtcTimestampType());

これで、タイムスタンプは、データベースに出入りする途中のJVMのタイムゾーンに関係するべきではありません。HTH。

この一般的な問題はHibernateによって処理されると思います。しかし、そうではありません！それを正しくするいくつかの「ハック」があります。

私が使用するのは、データベースに日付をLongとして格納することです。したがって、私は常に1/1/70以降のミリ秒で作業しています。次に、日付のみを返す/受け入れるクラスにゲッターとセッターを設定します。したがって、APIは同じままです。マイナス面は、私がデータベースに長いことを持っているということです。SQLを使用したSOでは、ほとんど<、>、=の比較しか行えません。

別のアプローチは、ここで説明されているカスタムマッピングタイプを使用することです：http : //www.hibernate.org/100.html

これに対処する正しい方法は、日付ではなくカレンダーを使用することです。カレンダーを使用すると、永続化する前にTimeZoneを設定できます。

注：愚かなstackoverflowは私にコメントさせないので、ここにデビッドaへの応答があります。

このオブジェクトをシカゴで作成した場合：

new Date(0);

Hibernateはそれを「12/31/1969 18:00:00」として保持します。日付にはタイムゾーンを含めないようにする必要があるため、調整が行われる理由がわかりません。

ここではいくつかのタイムゾーンが動作しています：

1. Javaの日付クラス（utilとsql）。UTCの暗黙的なタイムゾーンがあります。
2. JVMが実行されているタイムゾーン、および
3. データベースサーバーのデフォルトのタイムゾーン。

これらはすべて異なる場合があります。Hibernate / JPAには重大な設計上の欠陥があり、ユーザーはタイムゾーン情報がデータベースサーバーに保持されていることを簡単に確認できない（JVMで正しい時刻と日付を再構築できる）。

JPA / Hibernateを使用してタイムゾーンを（簡単に）格納する機能がない場合、情報は失われ、情報が失われると、（可能な場合は）構築するのにコストがかかります。

私は常にタイムゾーン情報を保存することをお勧めします（デフォルトである必要があります）。ユーザーは、タイムゾーンを最適化するオプション機能を持つ必要があります（表示にのみ影響しますが、日付には暗黙的なタイムゾーンがまだあります）。

申し訳ありませんが、この投稿は回避策を提供していません（他の場所で回答されています）が、常にタイムゾーン情報を常に保存することが重要である理由の合理化です。残念ながら、多くのコンピュータサイエンティストやプログラミングの専門家は、「情報の損失」の見方や、国際化のようなことを非常に困難にしている理由を理解していないという理由だけでタイムゾーンの必要性に反対しているようです。クライアントと組織内の人々が世界中を移動します。

Sourceforgeで私のプロジェクトを見てください。このプロジェクトには、標準のSQLの日付と時刻の型、およびJSR 310とJoda Timeのユーザー型があります。すべてのタイプが相殺問題に対処しようとします。http://sourceforge.net/projects/usertype/を参照してください

編集：このコメントに添付されたデレク・マハールの質問に応じて：

「クリス、ユーザータイプはHibernate 3以降で動作しますか？– Derek Mahar Nov 7 '10 at 12:30」

はい、これらのタイプはHibernate 3.6を含むHibernate 3.xバージョンをサポートしています。

日付はどのタイムゾーンにもありません（誰にとっても定義された瞬間からのミリ秒単位のオフィスです）が、基盤となる（R）DBは通常、タイムスタンプを政治形式（年、月、日、時間、分、秒など）で格納します。 ..）それはタイムゾーンの影響を受けます。

真剣に、Hibernate は何らかの形式のマッピング内でDBの日付がそのようなタイムゾーンにあることを通知できるようにする必要があります。これにより、Hibernate はそれをロードまたは保存するときに、それ自体は想定しません。

日付をUTCとしてDBに保存しvarchar、明示的なString <-> java.util.Date変換を使用したり、Javaアプリ全体をUTCタイムゾーンに設定したりするときにも同じ問題が発生しました（JVMが多くのアプリケーションで共有されます）。

そのため、オープンソースプロジェクトDbAssistがあり、データベースからの読み取り/書き込みをUTC日付として簡単に修正できます。JPAアノテーションを使用してエンティティのフィールドをマッピングしているので、Maven pomファイルに次の依存関係を含めるだけで済みます。

<dependency>
    <groupId>com.montrosesoftware</groupId>
    <artifactId>DbAssist-5.2.2</artifactId>
    <version>1.0-RELEASE</version>
</dependency>

次に@EnableAutoConfiguration、Springアプリケーションクラスの前にアノテーションを追加して、修正（Hibernate + Spring Bootの例の場合）を適用します。他のセットアップのインストール手順やその他の使用例については、プロジェクトのgithubを参照してください。

エンティティを変更する必要がないというのは良いことです。java.util.Dateフィールドをそのままにしておくことができます。

5.2.2使用しているHibernateのバージョンに対応している必要があります。プロジェクトで使用しているバージョンはわかりませんが、提供されている修正の完全なリストは、プロジェクトのgithubの wikiページで入手できます。修正がさまざまなHibernateバージョンで異なるのは、Hibernate作成者がリリース間でAPIを数回変更したためです。

内部的に、修正プログラムは、カスタムを作成するために、ダイベストクリム、シェーン、およびその他のいくつかのソースからのヒントを使用しますUtcDateType。次に、標準java.util.DateをUtcDateType、必要なすべてのタイムゾーン処理を処理するカスタムとマッピングします。タイプのマッピングは、@Typedef提供されたpackage-info.javaファイルの注釈を使用して行われます。

@TypeDef(name = "UtcDateType", defaultForType = Date.class, typeClass = UtcDateType.class),
package com.montrosesoftware.dbassist.types;

このようなタイムシフトが発生する理由とそれを解決するためのアプローチについて説明している記事は、こちらにあります。

Hibernateでは、注釈やその他の手段でタイムゾーンを指定することはできません。日付の代わりにカレンダーを使用する場合は、HIbernateプロパティAccessTypeを使用して回避策を実装し、マッピングを自分で実装できます。より高度なソリューションは、カスタムUserTypeを実装して日付またはカレンダーをマップすることです。両方のソリューションについては、こちらのブログ投稿で説明されています。http：//www.joobik.com/2010/11/mapping-dates-and-time-zones-with.html