[
https://issues.apache.org/jira/browse/AVRO-3476?focusedWorklogId=787357&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-787357
]
ASF GitHub Bot logged work on AVRO-3476:
----------------------------------------
Author: ASF GitHub Bot
Created on: 02/Jul/22 22:33
Start Date: 02/Jul/22 22:33
Worklog Time Spent: 10m
Work Description: kojiromike commented on code in PR #1634:
URL: https://github.com/apache/avro/pull/1634#discussion_r912406605
##########
lang/py/avro/io.py:
##########
@@ -586,26 +613,56 @@ def write_time_micros_long(self, datum: datetime.time) ->
None:
def _timedelta_total_microseconds(self, timedelta_: datetime.timedelta) ->
int:
return timedelta_.microseconds + (timedelta_.seconds + timedelta_.days
* 24 * 3600) * 10**6
- def write_timestamp_millis_long(self, datum: datetime.datetime) -> None:
+ def _write_timestamp_millis_long(self, datum: datetime.datetime,
tz:bool)->None:
"""
Encode python datetime object as long.
It stores the number of milliseconds from midnight of unix epoch, 1
January 1970.
"""
- datum = datum.astimezone(tz=avro.timezones.utc)
- timedelta = datum - datetime.datetime(1970, 1, 1, 0, 0, 0, 0,
tzinfo=avro.timezones.utc)
+ if tz:
+ datum = datum.astimezone(tz=avro.timezones.utc)
+ timedelta = datum - datetime.datetime(1970, 1, 1, 0, 0, 0, 0,
tzinfo=avro.timezones.utc if tz else None)
milliseconds = self._timedelta_total_microseconds(timedelta) // 1000
self.write_long(milliseconds)
- def write_timestamp_micros_long(self, datum: datetime.datetime) -> None:
Review Comment:
I think the distinction is important.
If the datum is naïve (has no tzinfo), then `datum - datetime.datetime(1970,
1, 1, 0, 0, 0, 0, tzinfo=avro.timezones.utc)` will fail with `TypeError: can't
subtract offset-naive and offset-aware datetimes`.
On the other hand, if the datum has `tzinfo`, but the type is local, then
the old implementation will happily encode it, including the difference between
the timezone and UTC in the result. I think that would most likely be done in
error. A datetime with a timezone is an inappropriate datum for encoding in a
localtimestamp logical type. In my implementation, this would crash (although
I'm considering adding a more friendly error message and type).
Issue Time Tracking
-------------------
Worklog Id: (was: 787357)
Time Spent: 1h 10m (was: 1h)
> Python implementation does not support local-timestamp-micros and
> local-timestamp-millis
> ----------------------------------------------------------------------------------------
>
> Key: AVRO-3476
> URL: https://issues.apache.org/jira/browse/AVRO-3476
> Project: Apache Avro
> Issue Type: Bug
> Components: python
> Affects Versions: 1.11.0
> Reporter: Eric
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Even though [they are present in the
> spec|https://avro.apache.org/docs/1.11.0/spec.html#Local+timestamp+(millisecond+precision)],
> the Python implementation does not support logical types
> local-timestamp-micros and local-timestamp-millis.
> When trying to use them, you get the following:
> {code:python}
> .../lib/python3.8/site-packages/avro/schema.py:1048: IgnoredLogicalType:
> Unknown local-timestamp-micros, using long.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)