All the confusion stems from daylight savings time, which is, I might add, a terrible, terrible idea. US time and European time are just subtly different enough to be annoying, but they don't have anything seriously surprising in them.
Python's spiffy new datetime module is aware of these issues, and apparently wishes to avoid becoming embroiled in the hothouse world of temporal politics. Odd design choice, considering that the language was designed by a time traveler. While this is irritating from the point of view of someone who wants to just stuff some date objects into strings formatted appropriately for different time zones, I can see why. The amount of work you'd need to do to properly support every time zone is staggering.
For example, it turns out that israeli daylight savings switch-over time is set every year by the ministry of the interior, so you can't actually anticipate it in software, only retroactively apply the dates.
I have no idea how japanese, russian, african, or chinese dates work yet, and I'm not really looking forward to find out unless it's in the form of a robust
tzinfo implementation...