[ 
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)

Reply via email to