-
- Downloads
[SPARK-15613] [SQL] Fix incorrect days to millis conversion due to Daylight Saving Time
## What changes were proposed in this pull request? Internally, we use Int to represent a date (the days since 1970-01-01), when we convert that into unix timestamp (milli-seconds since epoch in UTC), we get the offset of a timezone using local millis (the milli-seconds since 1970-01-01 in a timezone), but TimeZone.getOffset() expect unix timestamp, the result could be off by one hour (in Daylight Saving Time (DST) or not). This PR change to use best effort approximate of posix timestamp to lookup the offset. In the event of changing of DST, Some time is not defined (for example, 2016-03-13 02:00:00 PST), or could lead to multiple valid result in UTC (for example, 2016-11-06 01:00:00), this best effort approximate should be enough in practice. ## How was this patch tested? Added regression tests. Author: Davies Liu <davies@databricks.com> Closes #13652 from davies/fix_timezone.
Showing
- sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/util/DateTimeUtils.scala 48 additions, 3 deletions...la/org/apache/spark/sql/catalyst/util/DateTimeUtils.scala
- sql/catalyst/src/main/scala/org/apache/spark/sql/types/DateType.scala 1 addition, 1 deletion.../src/main/scala/org/apache/spark/sql/types/DateType.scala
- sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/util/DateTimeTestUtils.scala 40 additions, 0 deletions...rg/apache/spark/sql/catalyst/util/DateTimeTestUtils.scala
- sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/util/DateTimeUtilsSuite.scala 40 additions, 0 deletions...g/apache/spark/sql/catalyst/util/DateTimeUtilsSuite.scala
Loading
Please register or sign in to comment