[deepsun]

> pytz.timezone('America/New_York').localize( datetime(2019, 5, 21, 12, 30))

But wait, the datetime argument doesn't specify exact time instance, because it's "zone-less" itself!

So the above code can also be buggy/unclear, if instead of 2019 we'd use a datetime close to the switch time.

We should provide a time zone to the datetime param as well. Better GMT, otherwise we would need to localize that one as well, falling into an infinite loop.

[tinix]

pytz.localize() takes a naive date-time as an input.

The pytz docs are pretty much on-point, too:

> "The preferred way of dealing with times is to always work in UTC, converting to localtime only when generating output to be read by humans."

This, also, is the problem with this article, and is a really common pain-point across the spectrum of programmers, both new and seasoned.

[deepsun]

Yes, but my point still holds, the code above is buggy/unclear. And documentation supports this:

>>> loc_dt = eastern.localize(datetime(2002, 10, 27, 1, 30, 00))

>>> loc_dt.strftime(fmt) '2002-10-27 01:30:00 EST-0500'

> As you can see, the system has chosen one for you and there is a 50% chance of it being out by one hour.

And the solution, you're right, is to not use the code like above. But the article doesn't mention that at all.