[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.