Pelican 3.2

I hadn’t planned to write about Pelican again so soon, but 3.2 came out this past week, with a nice set of changes. I’ve installed it, and while I’m mostly happy with it, I’ve found a problem for my site.

I hesitate to call this a bug, because I imagine it’s working as the developers intend. It just breaks something non-standard that I am doing. For the dates on articles, I use the following as my default date format:

DEFAULT_DATE_FORMAT = '%A, %B %e, %Y'

When I first installed 3.2, that was interpreted like so:

I Googled around to figure out what was going on, and came across this post by Dr. Drang. As he explains, ‘%e’—which I use to get the day without a leading zero—is a format code that is not supported on all platforms. But Python’s strftime just calls the system strftime, so why would it stop working?

So I dug into the Pelican code. It appears¹ they’ve written a wrapper for strftime that skips over non-standard format codes. I have to assume this is for compatibility with Python 3.

At this point I had a choice: Accept dates with leading zeroes, or write some kind of workaround for Pelican’s strftime workaround.

I think you know what I did.

It was actually pretty easy. I just wrote a plugin that replaces the value of Article.locale_date with a call to the built-in strftime. And since I know ‘%e’ is supported on all the platforms I use, it’s portable enough for me. You can find it (and all my Pelican-related code) on GitHub.