Contructor issue with non-None timezone

Constructor of Arrow object (arrow.py) fails if tzinfo is non-None and if it does not contain field “zone”.

The problematic part:

            isinstance(tzinfo, dt_tzinfo)
            and hasattr(tzinfo, "localize")
            and tzinfo.zone
        ):

should be like

            isinstance(tzinfo, dt_tzinfo)
            and hasattr(tzinfo, "localize")
            and hasattr(tzinfo, "zone")
        ):

The change came since version 0.14.5

[mafycek]

Hi guys, hope that you are well. Say, I have a (simple) program like:

import arrow
import dateparser

date_that_succeds = "1990-01-01T00:00:00"
date_that_fails = "1990-01-01T00:00:00+00:00"

for date in [date_that_succeds, date_that_fails]:
    try:
        parsed_date = dateparser.parse(date, date_formats=None or ['%d %B %Y', '%d/%m/%y', '%d/%m/%Y', '%d.%m.%Y'])
        arrow_date = arrow.get(parsed_date)
        print(date_that_succeded, arrow_date)
    except:
        print("It failed on date " + date)

Results: with arrow 0.15.0 (since 0.14.5) The first date passes however the the second fails. with arrow 0.14.4 (I tested on 0.13.1) Both pass

Explanation of the failure: parsed_date is of type datetime with component variable tzinfo of type StaticTzInfo. The StaticTzInfo type has two component variables _StaticTzInfo__name of type str and _StaticTzInfo__offset of type timedelta. When such variable is inserted into arrow through get it fails in the constructor of arrow class because tzinfo in the constructor is of type StaticTzInfo that does not have component variable zone and that is why the interpreter says AttributeError: ‘StaticTzInfo’ object has no attribute ‘zone’

My comment: I do not know if the test of zone component is correct. If yes that it should test presence of the variable and then the value if that is needed.

Regression for this case would be really needed. Well, it could test more that one timezone and take into account some special ones with non-integer shifts.

Bye, Hynek

[systemcatch]

Thanks @mafycek, we will do some digging on this bug and look at fixes.

Useful note, you can wrap python code blocks like this.

```python INSERT BUG HERE ```