HyukjinKwon commented on code in PR #39239:
URL: https://github.com/apache/spark/pull/39239#discussion_r1058277577
##########
python/pyspark/sql/types.py:
##########
@@ -276,7 +276,15 @@ def toInternal(self, dt: datetime.datetime) -> int:
def fromInternal(self, ts: int) -> datetime.datetime:
if ts is not None:
# using int to avoid precision loss in float
- return datetime.datetime.fromtimestamp(ts //
1000000).replace(microsecond=ts % 1000000)
+ return (
+ datetime.datetime
+ # Set the time zone to UTC because the TIMESTAMP type stores
timestamps
+ # as the number of microseconds from the epoch of
1970-01-01T00:00:00.000000Z
+ # in the UTC time zone.
+ .fromtimestamp(ts // 1000000,
tz=datetime.timezone.utc).replace(
Review Comment:
I think there're implementation details that we should fix. My take was (see
quotes from
https://docs.python.org/3/library/datetime.html#aware-and-naive-objects)
> ... Whether a naive object represents Coordinated Universal Time (UTC),
local time, or time in some other timezone is purely up to the program ...
With `TimestampType`, naive datetimes are interpreted as a local time.
Meaning that `java.time.LocalDateTime`
With `TimestampNTZType`, naive datetimes are interpreted as a UTC time.
Meaning that `java.time.Instant`
But reading that codes, SQL side is opposite. My understanding was that
`TimestampType` is a local time per Spark's session timezone, and
`TimestampNTZType` is a UTC time.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]