Pelican time zone issues: resolved!
Today I decided to brave the depths of Pelican’s source and work out why time zones weren’t working as I expected them to. If I tried to put time zone information on the end of an article, it rejected that article. Why? This is what I tried:
Date: 2015-07-12 17:24 AEST
and the result:
pelican /home/fwaggle/src/fwaggle.org/content -o /home/fwaggle/src/fwaggle.org/output -s /home/fwaggle/src/fwaggle.org/pelicanconf.py
CRITICAL: AttributeError: 'NoneType' object has no attribute 'encode'
However, if I left the time zone specification out, the %Z format string in strftime() produced the expected output: ‘AEST’
What the fuck is going on?
After spending a lot of time wading through the sources, consulting the documentation for various data types in Python such as datetime, I finally arrived at what I think is the ugly truth: Time zone handling in Python is pretty hideous without pytz (which Pelican doesn’t use).
I did eventually arrive at a suitable solution which didn’t require me rolling up my sleeves and implementing pytz support inside Pelican. Python supports naive timezone offsets (as opposed to named time zones) in dateutil.parser.parse, which you can then handily output using %z (but not %Z, as the first element of tzinfo is None which causes the template to error out). which is acceptable under ISO 8601 and so works for my purposes. So I simply need to set the time zone on each article like so:
Date: 2015-07-12 17:24 +10:00
The resulting git changelog for my site isn’t pretty (involving updates to every single content page!) but the end result is I don’t have to do manual timezone math whenever I move. I may still hack pytz support into Pelican yet.
fwagglePublished:
Modified:
Filed under:
Location:
Horsham, VIC, AustraliaNavigation: Older Entry Newer Entry