Arrow: Issue with DST transition

[liosha]

>>> t = arrow.get("2019-10-27T02:21:01+03:00")
>>> t
<Arrow [2019-10-27T02:21:01+03:00]>
>>> t.to("Israel")
<Arrow [2019-10-27T01:21:01+03:00]>

Note the same tz offset but different hours

Same bug, another appearence:

>>> ut = 1572132061
>>> ut == arrow.get(ut).to("Israel").timestamp
False
>>> ut - arrow.get(ut).to("Israel").timestamp
3600

[systemcatch]

What version of python are you on @liosha?

[liosha]

I've checked with Python 2.7.12 and 2.7.16 (Ubuntu)

[systemcatch]

Hmmm that's interesting, I tested your example on python 3.7.4 and there's no error there that I can see. Could you test on 3.6+ as well?

I think the DST problems with arrow are slowly being fixed with the introduction of PEP 485 (fold attribute in datetime). Currently we only need to fix 2.7 and 3.5.

[liosha]

The same on 3.7.3

$ python3
Python 3.7.3 (default, Oct  7 2019, 12:56:13) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import arrow
>>> arrow.__version__
'0.15.2'
>>> arrow.get(1572132061).to("Israel").timestamp
1572128461

[salilb]

This issue exists on python 3.6.5 and arrow version 0.15.2 as well.

arrow.get(1572762479316/1000).replace(tzinfo='UTC').to('America/New_York')
<Arrow [2019-11-03T01:27:59.316000-04:00]>

<-- This is WRONG!!

whereas,

pytz.timezone('UTC').localize(datetime.datetime.utcfromtimestamp(1572762479316/1000.)).astimezone(pytz.timezone('America/New_York')).isoformat()
'2019-11-03T01:27:59.316000-05:00'

<-- This is CORRECT!!

[jmgurney]

confirmed on 3.7.5:

$python
Python 3.7.5 (default, Oct 18 2019, 23:59:39) 
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import arrow
>>> from datetime import datetime
>>> arrow.get(datetime(2019, 10, 27, 2, 21, 1), 'Israel')
<Arrow [2019-10-27T02:21:01+02:00]>
>>> t = arrow.get("2019-10-27T02:21:01+03:00")
>>> t
<Arrow [2019-10-27T02:21:01+03:00]>
>>> t.to("Israel")
<Arrow [2019-10-27T01:21:01+03:00]>
>>> arrow.__version__
'0.15.5'
>>> t.timestamp
1572132061
>>> t.to("Israel").timestamp
1572128461
>>> 

Looks like possible issue where the fact that the time is in DST (+2), but the standard time offset is the same (+3), so the time gets adjusted (-1 hour), but the DST flag isn't set, leaving it at +3.

[systemcatch]

@jmgurney this is fixed in #758 which we are hoping to get merged and released in March.