Timezones in XML-RPC

Timezones are hard. I’ve personally spent way too much time dealing with date and time formatting issues and stupidity. But in this case I want to mount a defence of XMLRPC, because I really quite like it. I feel the kung-foo blog gets its complaint wrong:

The Atom publishing protocol gets this right. It requires that dates sent and received specify the timezone. There’s no need to configure ecto as it knows Atom is a good boy. The problem is with XMLRPC. It does not have that requirement, and each blog system interprets dates differently.

The XMLRPC spec is really small. It’s very easy to implement from scratch if you need it, but you don’t normally need to do so, because sensible languages already have clients. And you don’t need to know about the XML side of things – it’s just RPC, you’re calling a named method on a specific endpoint with ordered parameters. Not very RESTful, I’ll grant you. But I like things that map well to the underlying realities.

One of the data types it knows how to encapsulate is a ‘date’, and it does this sensibly, serializing the date using ISO8601. If ‘not specifying timezones’ is an error, then it’s an error in the ISO8601 spec, because the spec allows a time without a timezone. XMLRPC isn’t judgemental. But ‘floating’ times do exist. And I can send them with XMLRPC.

Granted, they make little sense in the context of a blog entry. So the error is with the metaweblog (and associated) apis, which merely use XMLRPC as their transport. I will happily agree that the awful mess that is the metaweblog api is a pain. But don’t equate a cruddy API and buggy implementations with the underlying transport.