Der Blog

<rant>

Just spent hours hacking up these scripts again to make them handle timezones properly (originally because RSS pubDate elements require an RFC (2)822 date, and mine wasn't providing a timezone).

This was made particularly hard by

• the lack of support in MySQL for timezones in date types (why oh why?!?!)
• the insistence of MySQLdb (the library I'm using to interface with MySQL) on using an undocumented date class called DateTime instead of any of the standard Python libraries (actually, it seems to be a half-arsed form of mxDateTime, with no indication as to what's implemented - and of course having the same name (except for case) as one of the standard libraries makes it impossible to google for more info)
• the fact that Python knows what the current timezone is, but there is no straightforward way to find it out. There is an abstract tzinfo class but no subclasses or instances are defined, and of course, though the timezone of datetime.utcnow() is always the same, neither it nor datetime.now() have tzinfo fields unless you provide them! You have to figure it out manually by rounding datetime.now() - datetime.utcnow() to the nearest hour. Fscking irritating.

Steve pointed me at help("time") which gives a marginally less roundabout way of doing it... but that still involves checking one variable to see which of two other variables to use for the value, which you still have to convert into a string. All I want is the +/-XXXX descriptor! You'd think there'd be a single string variable or function to do this, but nooooo...

</rant>