[ 
https://issues.apache.org/jira/browse/ARROW-13896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429377#comment-17429377
 ] 

Joris Van den Bossche commented on ARROW-13896:
-----------------------------------------------

The error actually comes from python (we are using a datetime.datetime object 
to print the value of a pyarrow scalar), so not directly related with the 
support for such fixed offsets in Arrow itself:

{code}
>>> import pytz
>>> tzinfo = pytz.FixedOffset(120)
>>> tzinfo
pytz.FixedOffset(120)
>>> tzinfo.fromutc(datetime.datetime(2021, 1, 1))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-53-750509fdb01e> in <module>
----> 1 tzinfo.fromutc(datetime.datetime(2021, 1, 1))

ValueError: fromutc: dt.tzinfo is not self
{code}

I don't directly know if this is a bug in pytz, or a wrong usage from our side, 
though.

> [Python] Print of timestamp with timezone errors
> ------------------------------------------------
>
>                 Key: ARROW-13896
>                 URL: https://issues.apache.org/jira/browse/ARROW-13896
>             Project: Apache Arrow
>          Issue Type: Bug
>          Components: Python
>            Reporter: Jorge Leitão
>            Priority: Major
>
> {code:python}
> import pyarrow as pa
> a = pa.array([0], pa.timestamp('s', tz='+02:00'))
> print(a) # representation not correct?
> # <pyarrow.lib.TimestampArray object at 0x7f834c7cb9a8>
> # [
> #  1970-01-01 00:00:00
> # ]
> print(a[0])
> #Traceback (most recent call last):
> #  File "<stdin>", line 1, in <module>
> #  File "pyarrow/scalar.pxi", line 80, in pyarrow.lib.Scalar.__repr__
> #  File "pyarrow/scalar.pxi", line 463, in pyarrow.lib.TimestampScalar.as_py
> #  File "pyarrow/scalar.pxi", line 393, in pyarrow.lib._datetime_from_int
> #ValueError: fromutc: dt.tzinfo is not self
> {code}
> I am not really sure about this, but for a timezone of +02:00, shouldn't we 
> represent the 0 as {{"1970-01-01 02:00:00 +02:00"}}?
> The other should not crash imo.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to