You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ORC timestamp type is not straightforward, as though it apparently represents a timestamp without a timezone, its encoding & decoding is still dependent on the writer timezone (encoded in the stripe) and the reader timezone.
This is why the 1900 & 2038 integration tests are currently disabled as our implementation is incorrect:
FYI I've raised a PR to update ORC spec for timestamp: apache/orc#1867
Since that was what caused initial confusion for me, as some key implementation details were not mentioned in the spec leading to the initial inaccurate implementation
Note that the 2038 test is dependent on chronotope/chrono-tz#155 as it tests timestamps 2100 and beyond, which chrono_tz currently has inaccurate DST for
ORC timestamp type is not straightforward, as though it apparently represents a timestamp without a timezone, its encoding & decoding is still dependent on the writer timezone (encoded in the stripe) and the reader timezone.
This is why the 1900 & 2038 integration tests are currently disabled as our implementation is incorrect:
https://github.com/datafusion-contrib/datafusion-orc/blob/3369b5d7bb110dafde64288416c86bc8c996e465/tests/integration/main.rs#L155-L165
The text was updated successfully, but these errors were encountered: