[SPARK-16078] [SQL] from_utc_timestamp/to_utc_timestamp should not depends on local timezone #13784
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Jun 20, 2016
|
Test build #60869 has finished for PR 13784 at commit
|
|
cc @hvanhovell |
| val utcTerm = ctx.freshName("utc") | ||
| val tzClass = classOf[TimeZone].getName | ||
| ctx.addMutableState(tzClass, tzTerm, s"""$tzTerm = $tzClass.getTimeZone("$tz");""") | ||
| ctx.addMutableState(tzClass, utcTerm, s"""$utcTerm = $tzClass.getTimeZone("GMT");""") |
There was a problem hiding this comment.
UTC? Universal Time Coordinated and Greenwich Mean Time are in practice the same (GMT is a timezone, UTC is not); but lets use one for consistency.
|
Test build #60888 has finished for PR 13784 at commit
|
| def fromUTCTime(time: SQLTimestamp, timeZone: String): SQLTimestamp = { | ||
| val tz = TimeZone.getTimeZone(timeZone) | ||
| val offset = tz.getOffset(time / 1000L) | ||
| time + offset * 1000L |
There was a problem hiding this comment.
For fromUTCTime, this would result in a little bit overhead.
There was a problem hiding this comment.
Lets try to make it correct first. More optimizations are always possible.
|
Test build #60890 has finished for PR 13784 at commit
|
|
LGTM - thanks! Merging to master/2.0 |
asfgit
pushed a commit
that referenced
this pull request
Jun 22, 2016
…ends on local timezone ## What changes were proposed in this pull request? Currently, we use local timezone to parse or format a timestamp (TimestampType), then use Long as the microseconds since epoch UTC. In from_utc_timestamp() and to_utc_timestamp(), we did not consider the local timezone, they could return different results with different local timezone. This PR will do the conversion based on human time (in local timezone), it should return same result in whatever timezone. But because the mapping from absolute timestamp to human time is not exactly one-to-one mapping, it will still return wrong result in some timezone (also in the begging or ending of DST). This PR is kind of the best effort fix. In long term, we should make the TimestampType be timezone aware to fix this totally. ## How was this patch tested? Tested these function in all timezone. Author: Davies Liu <[email protected]> Closes #13784 from davies/convert_tz. (cherry picked from commit 20d411b) Signed-off-by: Herman van Hovell <[email protected]>
asfgit
pushed a commit
that referenced
this pull request
Oct 20, 2016
…ld not depends on local timezone ## What changes were proposed in this pull request? Back-port of #13784 to `branch-1.6` ## How was this patch tested? Existing tests. Author: Davies Liu <[email protected]> Closes #15554 from srowen/SPARK-16078.
zzcclp
pushed a commit
to zzcclp/spark
that referenced
this pull request
Oct 20, 2016
…ld not depends on local timezone ## What changes were proposed in this pull request? Back-port of apache#13784 to `branch-1.6` ## How was this patch tested? Existing tests. Author: Davies Liu <[email protected]> Closes apache#15554 from srowen/SPARK-16078. (cherry picked from commit 82e98f1)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
Currently, we use local timezone to parse or format a timestamp (TimestampType), then use Long as the microseconds since epoch UTC.
In from_utc_timestamp() and to_utc_timestamp(), we did not consider the local timezone, they could return different results with different local timezone.
This PR will do the conversion based on human time (in local timezone), it should return same result in whatever timezone. But because the mapping from absolute timestamp to human time is not exactly one-to-one mapping, it will still return wrong result in some timezone (also in the begging or ending of DST).
This PR is kind of the best effort fix. In long term, we should make the TimestampType be timezone aware to fix this totally.
How was this patch tested?
Tested these function in all timezone.