Apache Spark™ 3.0 における日付とタイムスタンプの詳細な解説

Apache Sparkは、構造化データと非構造化データの両方を処理するための非常に人気のあるツールです。構造化データの処理に関しては、整数、長整数、倍精度浮動小数点数、文字列など、多くの基本的なデータ型をサポートしています。Sparkはまた、開発者が理解するのが難しいことが多いDateやTimestampのような、より複雑なデータ型もサポートしています。このブログ記事では、Date型とTimestamp型の動作を完全に理解し、よくある問題を回避する方法を説明するために、詳細に掘り下げていきます。要約すると、このブログでは4つのパートを扱います。

1. Date型とその関連カレンダーの定義。Spark 3.0でのカレンダー切り替えについても説明します。
2. Timestamp型の定義とタイムゾーンとの関係。タイムゾーンオフセット解決の詳細と、Spark 3.0で使用されているJava 8の新しい時間APIにおける微妙な動作変更についても説明します。
3. Sparkで日付とタイムスタンプの値を構築するための一般的なAPI。
4. Sparkドライバーで日付とタイムスタンプオブジェクトを収集する際の一般的な落とし穴とベストプラクティス。

日付とカレンダー

Dateの定義は非常にシンプルです。年、月、日のフィールドの組み合わせ（例：年=2012、月=12、日=31）です。しかし、年、月、日の値には制約があり、日付の値が現実世界で有効な日である必要があります。例えば、月の値は1から12まで、日の値は年と月によって28/29/30/31のいずれかである必要があります。

これらの制約は、多くの可能なカレンダーのいずれかによって定義されます。地域によっては、旧暦のように特定の地域でのみ使用されるものもあります。歴史的なものとしては、ユリウス暦のように歴史的なもののみで使用されるものもあります。現在、グレゴリオ暦は事実上の国際標準であり、市民目的で世界中のほとんどの場所で使用されています。1582年に導入され、1582年以前の日付もサポートするように拡張されています。この拡張されたカレンダーはユリウス・グレゴリオ暦と呼ばれます。

バージョン3.0以降、Sparkはpandas、R、Apache Arrowのような他のデータシステムですでに使用されているユリウス・グレゴリオ暦を使用しています。Spark 3.0より前は、ユリウス暦とグレゴリオ暦の組み合わせを使用していました。1582年より前の日付にはユリウス暦が、1582年以降の日付にはグレゴリオ暦が使用されていました。これは、Java 8でjava.time.LocalDateに置き換えられたレガシーjava.sql.Date APIから引き継がれたもので、java.time.LocalDateもユリウス・グレゴリオ暦を使用しています。

注目すべきは、Date型はタイムゾーンを考慮しないことです。

タイムスタンプとタイムゾーン

Timestamp型は、新しいフィールド（時、分、秒（小数部を持つことができる）、およびグローバル（セッションスコープ）のタイムゾーン）でDate型を拡張します。地球上の具体的な時間インスタンスを定義します。例えば、(年=2012、月=12、日=31、時=23、分=59、秒=59.123456) でセッションタイムゾーンはUTC+01:00です。Parquetのような非テキストデータソースにタイムスタンプ値を書き出す場合、値はタイムゾーン情報を持たないインスタンス（UTCのタイムスタンプのような）になります。異なるセッションタイムゾーンでタイムスタンプ値を書き込み、読み込むと、時/分/秒フィールドの値が異なる場合がありますが、それらは実際には同じ具体的な時間インスタンスです。

時、分、秒フィールドには標準的な範囲があります。時間は0〜23、分と秒は0〜59です。Sparkはマイクロ秒精度までの小数秒をサポートしています。小数の有効範囲は0から999,999マイクロ秒です。

具体的な時間インスタンスであっても、タイムゾーンによって多くの異なる壁時計の値を観測することができます。

逆に、壁時計の任意の値は多くの異なる時間インスタンスを表すことができます。タイムゾーンオフセットにより、ローカルタイムスタンプを時間インスタンスに曖昧さなくバインドできます。通常、タイムゾーンオフセットは、グリニッジ標準時（GMT）またはUTC+0（協定世界時）からの時間オフセットとして定義されます。このようなタイムゾーン情報の表現は曖昧さを排除しますが、エンドユーザーにとっては不便です。ユーザーはAmerica/Los_AngelesやEurope/Parisのような、地球上の場所を指定することを好みます。

ゾーンオフセットからのこの追加レベルの抽象化は、生活を楽にしますが、それ自体に問題をもたらします。例えば、タイムゾーン名をオフセットにマッピングするために特別なタイムゾーンデータベースを維持する必要があります。SparkはJVM上で実行されるため、マッピングをJava標準ライブラリに委任します。Java標準ライブラリは、Internet Assigned Numbers Authority Time Zone Database (IANA TZDB)からデータをロードします。さらに、Javaの標準ライブラリのマッピングメカニズムには、Sparkの動作に影響を与えるいくつかのニュアンスがあります。これらのニュアンスの一部を以下に焦点を当てます。

Java 8以降、JDKは日付・時刻操作とタイムゾーンオフセット解決のための新しいAPIを公開しており、Sparkはバージョン3.0でこの新しいAPIに移行しました。タイムゾーン名をオフセットにマッピングするソースは同じIANA TZDBですが、Java 8以降とJava 7では実装が異なります。

例として、

America/Los_Angelesタイムゾーンにおける1883年より前のタイムスタンプを見てみましょう。1883-11-10 00:00:00。この年は他の年とは際立っています。なぜなら、1883年11月18日に、すべての北米鉄道が新しい標準時間システムに切り替わり、それ以降、時刻表を管理するようになったからです。
Java 7の時間APIを使用すると、ローカルタイムスタンプのタイムゾーンオフセットを-08:00として取得できます。

Java 8 API関数は異なる結果を返します。

1883年11月18日より前は、時刻はローカルな問題であり、ほとんどの都市や町は、（例えば教会の尖塔や宝石店の窓にある）よく知られた時計によって維持される、ある種のローカル太陽時を使用していました。そのため、このような奇妙なタイムゾーンオフセットが見られます。

この例は、Java 8関数がより正確であり、IANA TZDBの歴史的データを考慮していることを示しています。Java 8時間APIに切り替えた後、Spark 3.0はこの改善から自動的に恩恵を受け、タイムゾーンオフセットの解決においてより正確になりました。

前述のように、Spark 3.0は日付型にもユリウス・グレゴリオ暦を採用しました。タイムスタンプ型についても同様です。ISO SQL:2016標準は、タイムスタンプの有効範囲を0001-01-01 00:00:00から9999-12-31 23:59:59.999999までと宣言しています。Spark 3.0はこの標準に完全に準拠しており、この範囲内のすべてのタイムスタンプをサポートしています。Spark 2.4以前と比較して、以下のサブ範囲を強調すべきです。

1. 0001-01-01 00:00:00..1582-10-03 23:59:59.999999。Spark 2.4はユリウス暦を使用しており、標準に準拠していません。Spark 3.0はこの問題を修正し、年、月、日などを取得するようなタイムスタンプの内部操作でユリウス・グレゴリオ暦を適用します。カレンダーが異なるため、Spark 2.4には存在するがSpark 3.0には存在しない日付もあります。例えば、1000-02-29はグレゴリオ暦では1000年は閏年ではないため、有効な日付ではありません。また、Spark 2.4はこのタイムスタンプ範囲のタイムゾーン名をゾーンオフセットに誤って解決します。
2. 1582-10-04 00:00:00..1582-10-14 23:59:59.999999。これはSpark 3.0では有効なローカルタイムスタンプの範囲ですが、Spark 2.4ではそのようなタイムスタンプは存在しませんでした。
3. 1582-10-15 00:00:00..1899-12-31 23:59:59.999999。Spark 3.0は、IANA TZDBからの歴史的データを使用してタイムゾーンオフセットを正しく解決します。Spark 3.0と比較して、Spark 2.4は、上記の例で示したように、場合によってはタイムゾーン名からゾーンオフセットを誤って解決する可能性があります。
4. 1900-01-01 00:00:00..2036-12-31 23:59:59.999999。Spark 3.0とSpark 2.4はどちらもANSI SQL標準に準拠しており、日付の月などの日時操作でグレゴリオ暦を使用します。
5. 2037-01-01 00:00:00..9999-12-31 23:59:59.999999。Spark 2.4では、JDKのバグ#8073446により、タイムゾーンオフセット、特に夏時間オフセットを誤って解決する可能性があります。Spark 3.0ではこの欠陥はありません。

タイムゾーン名をオフセットにマッピングするもう1つの側面は、夏時間（DST）や別の標準タイムゾーンオフセットへの切り替えによって発生する可能性のあるローカルタイムスタンプの重複です。たとえば、3 November 2019, 02:00:00には、時計が1時間戻されて01:00:00になりました。ローカルタイムスタンプ

2019-11-03 01:30:00 America/Los_Angeles は、2019-11-03 01:30:00 UTC-08:00 または 2019-11-03 01:30:00 UTC-07:00 のいずれかにマッピングできます。オフセットを指定せずにタイムゾーン名のみを設定した場合（例：'2019-11-03 01:30:00 America/Los_Angeles'）、Spark 3.0は通常「夏時間」に対応する早い方のオフセットを採用します。この動作は、「冬時間」のオフセットを採用するSpark 2.4とは異なります。ギャップが発生し、時計が進む場合、有効なオフセットはありません。通常の1時間の夏時間の変更の場合、Sparkはそのようなタイムスタンプを次の有効な「夏時間」に対応するタイムスタンプに移動します。

上記の例からわかるように、タイムゾーン名をオフセットにマッピングすることは曖昧であり、一対一ではありません。可能な場合は、タイムスタンプを作成する際に正確なタイムゾーンオフセットを指定することをお勧めします。たとえば、timestamp '2019-11-03 01:30:00 UTC-07:00' のようにします。

ゾーン名からオフセットへのマッピングから離れて、ANSI SQL標準を見てみましょう。ANSI SQL標準は2種類のタイムスタンプを定義しています。

1. TIMESTAMP WITHOUT TIME ZONE または TIMESTAMP - （年、月、日、時、分、秒）のローカルタイムスタンプ。これらの種類のタイムスタンプはいずれのタイムゾーンにもバインドされておらず、実際には壁時計のタイムスタンプです。
2. TIMESTAMP WITH TIME ZONE - （年、月、日、時、分、秒、タイムゾーン時、タイムゾーン分）のゾーンタイムスタンプ。タイムスタンプは、UTCタイムゾーンでの瞬間と、各値に関連付けられた（時と分での）タイムゾーンオフセットを表します。

TIMESTAMP WITH TIME ZONE のタイムゾーンオフセットは、タイムスタンプが表す物理的な瞬間に影響を与えません。なぜなら、それは他のタイムスタンプコンポーネントによって与えられるUTCタイムインスタントによって完全に表されるからです。代わりに、タイムゾーンオフセットは、表示、日付/時刻コンポーネントの抽出（例：EXTRACT）、または月をタイムスタンプに追加するなど、タイムゾーンを知る必要があるその他の操作のためのタイムスタンプ値のデフォルトの動作にのみ影響します。

Spark SQLは、タイムスタンプ型をTIMESTAMP WITH SESSION TIME ZONEとして定義します。これは、（YEAR、MONTH、DAY、HOUR、MINUTE、SECOND、SESSION TZ）フィールドの組み合わせであり、YEARからSECONDまでのフィールドはUTCタイムゾーンでの時間インスタントを識別し、SESSION TZはSQL設定spark.sql.session.timeZoneから取得されます。セッションタイムゾーンは次のように設定できます。

• ゾーンオフセット '(+|-)HH:mm'。この形式により、物理的な瞬間を曖昧さなく定義できます。
• リージョンID 'area/city' の形式のタイムゾーン名。たとえば、'America/Los_Angeles' のようなものです。この形式のタイムゾーン情報は、ローカルタイムスタンプの重複など、上記で説明した問題の一部を抱えています。ただし、各UTC時間インスタントは、リージョンIDベースのタイムゾーンに対して1つのタイムゾーンオフセットと一意に関連付けられており、その結果、リージョンIDベースのタイムゾーンを持つ各タイムスタンプは、ゾーンオフセットを持つタイムスタンプに一意に変換できます。

デフォルトでは、セッションタイムゾーンはJava仮想マシンのデフォルトタイムゾーンに設定されています。

SparkのTIMESTAMP WITH SESSION TIME ZONEは、次とは異なります。

1. TIMESTAMP WITHOUT TIME ZONE。この型の値は複数の物理的な時間インスタントにマッピングできますが、TIMESTAMP WITH SESSION TIME ZONEの値はすべて具体的な物理的な時間インスタントです。SQL型は、たとえばUTC+0のような固定タイムゾーンオフセットをすべてのセッションで使用することでエミュレートできます。その場合、UTCでのタイムスタンプをローカルタイムスタンプと見なすことができます。
2. TIMESTAMP WITH TIME ZONE。SQL標準によると、この型の列値は異なるタイムゾーンオフセットを持つことができます。これはSpark SQLではサポートされていません。

グローバル（セッションスコープ）タイムゾーンに関連付けられたタイムスタンプは、Spark SQLによって新しく発明されたものではないことに注意する必要があります。OracleのようなRDBMSも、タイムスタンプに同様の型を提供しています：TIMESTAMP WITH LOCAL TIME ZONE。

日付とタイムスタンプの構築

Spark SQLは、日付とタイムスタンプ値を構築するためのいくつかの方法を提供しています。

1. パラメータなしのデフォルトコンストラクタ：CURRENT_TIMESTAMP()およびCURRENT_DATE()。
2. INT、LONG、STRINGなどの他のプリミティブSpark SQL型から
3. PythonのdatetimeやJavaクラスjava.time.LocalDate/Instantのような外部型から。
4. CSV、JSON、Avro、Parquet、ORCなどのデータソースからの逆シリアル化。

Spark 3.0で導入されたMAKE_DATE関数は、YEAR、MONTH、DAYの3つのパラメータを取り、DATE値を生成します。すべての入力パラメータは、可能な限りINT型に暗黙的に変換されます。この関数は、結果の日付がProleptic Gregorianカレンダーで有効な日付であることを確認します。そうでない場合はNULLを返します。たとえば、PySparkでは次のようになります。

DataFrameの内容を表示するには、show()アクションを呼び出します。これは、エグゼキュータで日付を文字列に変換し、文字列をドライバに転送してコンソールに出力します。

同様に、MAKE_TIMESTAMP関数を使用してタイムスタンプ値を生成できます。MAKE_DATEと同様に、日付フィールドに対して同じ検証を実行し、さらに時間フィールドHOUR (0-23)、MINUTE (0-59)、SECOND (0-60)を受け入れます。SECONDは、秒をマイクロ秒精度まで小数部で渡すことができるため、Decimal（精度=8、スケール=6）型です。たとえば、PySparkでは次のようになります。

日付の場合と同様に、ts DataFrameの内容をshow()アクションを使用して表示しましょう。同様の方法で、show()はタイムスタンプを文字列に変換しますが、今度はSQL設定spark.sql.session.timeZoneで定義されたセッションタイムゾーンを考慮に入れます。これは次の例で確認できます。

最後のタイムスタンプを作成できません。この日付は無効です。2019年はうるう年ではありません。

上記の例ではタイムゾーン情報を指定していないことに気づいたかもしれません。その場合、SparkはSQL設定spark.sql.session.timeZoneからタイムゾーンを取得し、関数呼び出しに適用します。MAKE_TIMESTAMPの最後のパラメータとして渡すことで、別のタイムゾーンを選択することもできます。PySparkでの例を次に示します。

この例が示すように、Sparkは指定されたタイムゾーンを考慮しますが、すべてのローカルタイムスタンプをセッションタイムゾーンに調整します。MAKE_TIMESTAMP関数に渡された元のタイムゾーンは失われます。なぜなら、TIMESTAMP WITH SESSION TIME ZONE型は、すべての値が1つのタイムゾーンに属すると想定しており、値ごとにタイムゾーンを保存することさえしないからです。TIMESTAMP WITH SESSION TIME ZONEの定義によれば、SparkはローカルタイムスタンプをUTCタイムゾーンに保存し、日付/時刻フィールドを抽出したり、タイムスタンプを文字列に変換したりする際にはセッションタイムゾーンを使用します。

また、タイムスタンプはキャスティングを通じてLONG型から構築することもできます。LONG列にエポック1970-01-01 00:00:00Zからの秒数が含まれている場合、Spark SQLのTIMESTAMPにキャストできます。

残念ながら、このアプローチでは秒の小数部分を指定できません。将来的には、Spark SQLはエポックからの秒、ミリ秒、マイクロ秒でタイムスタンプを作成するための特別な関数、timestamp_seconds()、timestamp_millis()、timestamp_micros()を提供する予定です。

別の方法として、STRING型の値から日付とタイムスタンプを構築する方法があります。特別なキーワードを使用してリテラルを作成できます。

または、列のすべての値に適用できるキャスティングを通じて行います。

入力タイムスタンプ文字列は、指定されたタイムゾーンのローカルタイムスタンプとして解釈されます。タイムゾーンが入力文字列で省略されている場合は、セッションタイムゾーンとして解釈されます。通常とは異なるパターンの文字列は、to_timestamp()関数を使用してタイムスタンプに変換できます。サポートされているパターンは、フォーマットと解析のための日時パターンで説明されています。

パターンを指定しない場合、この関数はCASTと同様に動作します。

使いやすさのために、Spark SQLは文字列を受け取りタイムスタンプと日付を返すすべての方法で、特別な文字列値を認識します。

• epoch は date '1970-01-01' または timestamp '1970-01-01 00:00:00Z' のエイリアスです。
• now はセッションタイムゾーンでの現在のタイムスタンプまたは日付です。単一のクエリ内では常に同じ結果を生成します。
• today は TIMESTAMP 型の現在の日の始まり、または DATE 型の現在の日のことです。
• tomorrow はタイムスタンプの次の日の始まり、または DATE 型の次の日のことです。
• yesterday は現在の日の前日、または TIMESTAMP 型の場合はその日の始まりです。

例:

Sparkの優れた機能の1つは、ドライバー側で既存の外部オブジェクトコレクションからDatasetsを作成し、対応する型の列を作成することです。Sparkは外部型のインスタンスを意味的に等価な内部表現に変換します。PySparkを使用すると、例えばPythonコレクションからDATEおよびTIMESTAMP列を持つDatasetを作成できます。

PySparkは、Pythonのdatetimeオブジェクトをドライバー側で内部Spark SQL表現に変換します。この際、システムのタイムゾーンが使用されますが、これはSparkのセッションタイムゾーン設定spark.sql.session.timeZoneとは異なる場合があります。内部値には元のタイムゾーンに関する情報は含まれません。並列化された日付とタイムスタンプ値に対する将来の操作は、TIMESTAMP WITH SESSION TIME ZONE型の定義に従って、Spark SQLセッションタイムゾーンのみを考慮します。

上記でPythonコレクションについて示したのと同様の方法で、SparkはJava/Scala APIで外部日付/時刻型として以下の型を認識します。

• Spark SQLのDATE型に対する外部型としてのjava.sql.Dateおよびjava.time.LocalDate
• TIMESTAMP型としてのjava.sql.Timestampおよびjava.time.Instant。

java.sql.*とjava.time.*型の間には違いがあります。java.time.LocalDateとjava.time.InstantはJava 8で追加され、これらの型はProleptic Gregorian calendarに基づいています。これはSparkバージョン3.0以降で使用されているものと同じカレンダーです。java.sql.Dateとjava.sql.Timestampは、その下に別のカレンダー（ハイブリッドカレンダー（ユリウス暦 + グレゴリオ暦、1582-10-15以降））を持っています。これは、Sparkバージョン3.0より前のレガシーカレンダーと同じです。異なるカレンダーシステムのため、Sparkは内部Spark SQL表現への変換中に追加の操作を実行する必要があり、入力日付/タイムスタンプをあるカレンダーから別のカレンダーにリベースする必要があります。リベース操作は、1900年以降の最新のタイムスタンプではわずかなオーバーヘッドがありますが、古いタイムスタンプではより大きくなる可能性があります。

以下の例は、Scalaコレクションからタイムスタンプを作成する方法を示しています。最初の例では、文字列からjava.sql.Timestampオブジェクトを構築します。valueOfメソッドは、入力文字列をデフォルトのJVMタイムゾーンのローカルタイムスタンプとして解釈しますが、これはSparkのセッションタイムゾーンとは異なる場合があります。特定のタイムゾーンでjava.sql.Timestampまたはjava.sql.Dateのインスタンスを構築する必要がある場合は、java.text.SimpleDateFormat（およびそのsetTimeZoneメソッド）またはjava.util.Calendarを参照することをお勧めします。

同様に、java.sql.Dateまたはjava.LocalDateのコレクションからDATE列を作成できます。java.LocalDateインスタンスの並列化は、SparkのセッションタイムゾーンまたはJVMのデフォルトタイムゾーンとは完全に独立していますが、java.sql.Dateインスタンスの並列化については同じことは言えません。ニュアンスがあります。

1. java.sql.Dateインスタンスは、ドライバーのデフォルトJVMタイムゾーンのローカル日付を表します。
2. Spark SQL値への正しい変換のためには、ドライバーとエグゼキュータのデフォルトJVMタイムゾーンが同じである必要があります。

カレンダーとタイムゾーンに関連する問題を回避するために、Java/Scalaコレクションのタイムスタンプまたは日付の並列化において、Java 8の型java.LocalDate/Instantを外部型として使用することをお勧めします。

日付とタイムスタンプの収集

並列化の逆操作は、エグゼキュータからドライバーに日付とタイムスタンプを収集し、外部型のコレクションを返すことです。上記の例では、collect()アクションを通じてDataFrameをドライバーに戻すことができます。

Sparkは、日付とタイムスタンプ列の内部値をエグゼキュータからドライバにUTCタイムゾーンのタイムインスタントとして転送し、Spark SQLセッションタイムゾーンを使用せずに、ドライバでシステムのタイムゾーンのPython datetimeオブジェクトに変換します。collect()は、前のセクションで説明したshow()アクションとは異なります。show()はタイムスタンプを文字列に変換する際にセッションタイムゾーンを使用し、結果の文字列をドライバに収集します。

JavaおよびScala APIでは、Sparkはデフォルトで次の変換を実行します。

• Spark SQLのDATE値はjava.sql.Dateのインスタンスに変換されます。
• タイムスタンプはjava.sql.Timestampのインスタンスに変換されます。

これらの変換は両方とも、ドライバのデフォルトのJVMタイムゾーンで実行されます。このように、Date.getDay()、getHour()などから取得できる日付/時刻フィールドと、Spark SQL関数DAY、HOURから取得できるフィールドを同じにするには、ドライバのデフォルトJVMタイムゾーンとエグゼキュータのセッションタイムゾーンを同じにする必要があります。

java.sql.Date/Timestampから日付/タイムスタンプを作成するのと同様に、Spark 3.0はProleptic Gregorianカレンダーからハイブリッドカレンダー（Julian + Gregorian）へのリベースを実行します。この操作は、現代の日付（1582年以降）とタイムスタンプ（1900年以降）ではほぼ無料ですが、古い日付やタイムスタンプではオーバーヘッドが発生する可能性があります。

これらのカレンダー関連の問題を回避し、Java 8以降で追加されたjava.time型を返すようにSparkに依頼できます。SQL設定spark.sql.datetime.java8API.enabledをtrueに設定すると、Dataset.collect()アクションは次を返します。

• Spark SQLのDATE型の場合はjava.time.LocalDate
• Spark SQLのTIMESTAMP型の場合はjava.time.Instant

Java 8型とSpark SQL 3.0は両方ともProleptic Gregorianカレンダーに基づいているため、これらの変換はカレンダー関連の問題の影響を受けなくなりました。collect()アクションは、もはやデフォルトのJVMタイムゾーンに依存しません。タイムスタンプの変換は、タイムゾーンに全く依存しなくなりました。日付の変換に関しては、SQL設定spark.sql.session.timeZoneのセッションタイムゾーンを使用します。たとえば、DATEおよびTIMESTAMP列を持つDatasetを見てみましょう。デフォルトのJVMタイムゾーンをEurope/Moscowに設定しますが、セッションタイムゾーンはAmerica/Los_Angelesに設定します。

show()アクションは、セッションタイムAmerica/Los_Angelesでタイムスタンプを表示しますが、Datasetを収集すると、java.sql.Timestampに変換され、toStringメソッドによってEurope/Moscowで表示されます。

実際、ローカルタイムスタンプ2020-07-01 00:00:00はUTCでは2020-07-01T07:00:00Zです。Java 8 APIを有効にしてDatasetを収集すると、これが確認できます。

java.time.Instantオブジェクトは、グローバルJVMタイムゾーンとは無関係に、後で任意のローカルタイムスタンプに変換できます。これは、java.sql.Timestampに対するjava.time.Instantの利点の1つです。前者はグローバルJVM設定の変更を必要とし、同じJVM上の他のタイムスタンプに影響します。したがって、アプリケーションが異なるタイムゾーンで日付またはタイムスタンプを処理し、Java/ScalaのDataset.collect() APIを介してドライバにデータを収集する際に、アプリケーションが衝突しないようにするには、SQL設定spark.sql.datetime.java8API.enabledを使用してJava 8 APIに切り替えることをお勧めします。

結論

このブログ投稿では、Spark SQLのDATEおよびTIMESTAMP型について説明しました。他のプリミティブSpark SQL型および外部Java型から日付およびタイムスタンプ列を構築する方法、および日付およびタイムスタンプ列を外部Java型としてドライバに収集する方法を示しました。バージョン3.0以降、Sparkはハイブリッドカレンダー（JulianとGregorianカレンダーを組み合わせたもの）からProleptic Gregorianカレンダー（詳細についてはSPARK-26651を参照）に切り替えました。これにより、以前に示したような多くの問題を排除することができました。以前のバージョンとの後方互換性のために、Sparkは依然としてcollectのようなアクションからハイブリッドカレンダー（java.sql.Dateおよびjava.sql.Timestamp）でタイムスタンプと日付を返します。Java/Scalaのcollectアクションを使用する際にカレンダーとタイムゾーンの解決の問題を回避するには、SQL設定spark.sql.datetime.java8API.enabledを介してJava 8 APIを有効にできます。Databricks Runtime 7.0の一部として、Databricksで無料で試してみてください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事