Skip to content

[SkipRecovery] Re-enable CORRECTED Parquet timestamp checks [databricks] #15969

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wjxiz1992 wants to merge 1 commit into
base: main
Choose a base branch
from
+8 −5
Open

[SkipRecovery] Re-enable CORRECTED Parquet timestamp checks [databricks] #15969

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions docs/compatibility.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -312,10 +312,13 @@ satisfy the query, the ORC read falls back to the CPU as it is a metadata-only q
## Parquet

The Parquet format has more configs because there are multiple versions with some compatibility
issues between them. Dates and timestamps are where the known issues exist. For reads when
`spark.sql.legacy.parquet.datetimeRebaseModeInWrite` is set to `CORRECTED`
[timestamps](https://github.com/NVIDIA/cudf-spark/issues/132) before the transition between the
Julian and Gregorian calendars are wrong, but dates are fine. When
issues between them. Dates and timestamps are where the known issues exist. The
[CORRECTED timestamp discrepancy](https://github.com/NVIDIA/cudf-spark/issues/132) was reported
on Spark 3.0. For files written by the CPU on supported Spark versions with both
`spark.sql.parquet.datetimeRebaseModeInWrite` and `spark.sql.parquet.int96RebaseModeInWrite`
set to `CORRECTED`, GPU reads support timestamps before the transition between the Julian
and Gregorian calendars. This does not change LEGACY rebasing or INT96 timestamp-conversion
limitations. When
`spark.sql.legacy.parquet.datetimeRebaseModeInWrite` is set to `LEGACY`, the read may fail for
values occurring before the transition between the Julian and Gregorian calendars, i.e.: date <= 1582-10-04.

Expand Down
2 changes: 1 addition & 1 deletion integration_tests/src/main/python/parquet_test.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@ def read_parquet_sql(data_path):
StructGen([['child0', ArrayGen(byte_gen)], ['child1', byte_gen], ['child2', float_gen], ['child3', decimal_gen_64bit]]),
ArrayGen(StructGen([['child0', string_gen], ['child1', double_gen], ['child2', int_gen]]))] +
parquet_map_gens + decimal_gens,
pytest.param([timestamp_gen], marks=pytest.mark.xfail(reason='https://github.com/NVIDIA/spark-rapids/issues/132'))]
[timestamp_gen]]

# test with original parquet file reader, the multi-file parallel reader for cloud, and coalesce file reader for
# non-cloud
Expand Down
Loading