AttributeError: 'tzlocal' object has no attribute 'localize'

[boyan-soubachov]

The recent release (0.22.3) causes a new issue.

The message AttributeError: 'tzlocal' object has no attribute 'localize' occurs when calling the next() method with a default_utc=True and a now=datetime arguments.

The input datetime (to the now argument) is datetime.utcnow().

This is exactly in the lines changed in the 0.22.3 release and was not an issue in 0.22.2.

[boyan-soubachov]

Update: This occurs when the input object to the now= argument has timezone info.
Example:

>>> ref = dateutil_parser.parse("2018-10-20T07:00:00Z")
>>> ref
datetime.datetime(2018, 10, 20, 7, 0, tzinfo=tzutc())
>>> next = cron.next(now=ref, default_utc=True)

results in AttributeError: 'tzutc' object has no attribute 'localize'

>>> now_ref = datetime.utcnow()
>>> now_ref
datetime.datetime(2018, 11, 20, 8, 24, 5, 793054)
>>> next = cron.next(now=now_ref, default_utc=True)

is fine.

[josiahcarlson]

Okay, you are using dateutil as your timezone library. I will have to write different code for dateutil and pytz.

[boyan-soubachov]

👍 . I solved it on my side by removing the timezone info from the datetime object, i.e. ref = ref.replace(tzinfo=None) before calling the next() method. That's a quick, nasty hack which undoes all of the timezone work you put in.

[josiahcarlson]

That definitely works for UTC, though will go weird for non-UTC timezones. Did you need different timezone support? I should fix it anyway, apparently I was using a pytz-internal interface, not one necessarily shared by the default Python timezone interface (the default interface is what was broken before).

[boyan-soubachov]

I am using UTC, no special requirement for other timezones from my side but it does seem like the latest master merge you did brought whatever timezone the input had to UTC. I think that's a perfectly good way to go about it but the problem is more of the exception pytz causes when you try to bring a datetime to UTC/local with the localize() method.

I don't use pytz in my project but I would assume it would be a dependency of yours and so I'm really surprised that I would get the exception if parse-crontab would automatically pip install pytz.

[josiahcarlson]

No, we don't automatically install pytz, but we do test against it, and the only timezone tests are against pytz. I had been reading some docs on what should be available in tzinfo, which is why I was using localize, but I forgot to keep a link, and I'm not finding it right now.

I'm duplicating the tests and am going to run it through again. On the pytz side of things raising exceptions; we don't normally add timezone information purposefully, and our use of localize in those cases seems to be fine (at least in the DST cutover in spring / fall in what I've tested). I have used pytz with parse-crontab along with my other project, rpqueue, and using local time can be useful in those cases for scheduling maintenance tasks.

I'll get a version out that works with not pytz, and is tested specifically with dateutil (and maybe Python's built in local timezone), so most folks should be covered going forward.

[josiahcarlson]

Okay, just released 0.22.4, which should fix dateutil users.

Didn't need to do anything for folks using datetime.now(), as there is no tzinfo attached to that object.

Thank you for the bug report, let me know if this works or breaks for you.