I guess we still like solar time a lot ;-) The point is, for date/time calculations, you need a numeric representation that increases strictly monotonically (an epoch time). If you introduce unpredictable modifications to that (leap seconds), the nice calculation falls apart, you end up with a lookup table such as the one in the IANA timezone database / TZif files (the blog post calls it the Olson library).
I think naive datetime would be fine, even if it resembles UTC - as long as you don't mix in a serial representation. The module documentation says, "Whether a naive object represents Coordinated Universal Time (UTC), local time, or time in some other timezone is purely up to the program, [...]". That definition goes down the drain imho once you call `.timestamp()`, which gives you Unix time as a serial representation (epoch time), which must be referenced against aware datetime, namely 1970-01-01 00:00 UTC. Same trouble vice versa (`.fromtimestamp()`).
Well, pytz actually is technically flawed at the moment because it cannot read TZif Version 2+ files, so it breaks for dates >2038 (and it would break if you tried to point it at system data generated with zic's "slim" mode), see this: https://github.com/stub42/pytz/issues/48
But you are right that pandas' use of pytz is benign and as far as I know doesn't suffer the same usability issues.
