We're almost ready to begin public beta testing of our implementation of the MetaWeblog API for MSN Spaces. As with most technology specifications, the devil has been in the details of figuring out how common practice differs from what is in the spec.

One place where we hit on some gotchas is how dates and times are defined in the XML-RPC specification which the MetaWeblog API uses. From the spec

Scalar <value>s

<value>s can be scalars, type is indicated by nesting the value inside one of the tags listed in this table:

Tag Type Example
<dateTime.iso8601> date/time 19980717T14:08:55

The reason the above definition of a date/time type is a gotcha is that the date in the example is in the format YYYYMMDDTHH:MM:SS. Although this is a valid ISO 8601 date, most Web applications that support ISO 8601 dates usually support the subset defined in the W3C Note on Dates and Time Formats which is of the form YYYY-MM-DDTHH:MM:SS. Subtle but important difference.

Another thing that had me scratching my head was related to timezones in XML-RPC. The spec states

  • What timezone should be assumed for the dateTime.iso8601 type? UTC? localtime?

    Don't assume a timezone. It should be specified by the server in its documentation what assumptions it makes about timezones.

This just seems broken to me. What if you are a generic blog posting client like Blogjet or W.Bloggar which isn't tied to one particular server? It would seem that the only sane thing that can happen here is for the dates & times from the server to always be used and dates & times from clients be ignored since they are useless without timezones. If I get a blog post creation date of September 29th at 4:30 PM from a client, I can't use it since without a timezone I'll likely date the entry incorrectly by anything from a few hours to an entire day.

It probably would have been better to retrofit timezones into the spec than just punting on the problem as is the case now. I wonder what other interesting gotchas are lurking out there for our beta testers to find. :)


Thursday, September 29, 2005 7:24:29 PM (GMT Daylight Time, UTC+01:00)
Now imagine the fun of trying to write blog clients for tools which have all had to make their own decisions about time zones.
It's undoubtedly what's made me the twisted and bitter old man I am to do...
My experience (painful) is that the majority of blog tools, with one notable exception starting with "C", assume UTC.
As you've observed, if you assume local server time and the client is using either UTC or their local time, the results will not be pretty (in short, most posts from outside the US will be future dated).
Out of interest, I'm pretty sure dasBlog assumes UTC, although I might be mistaken about that since it's been a while since I checked.

The uncomfortable truth is that to gain any real benefit from having chosen MetaWeblog API, it's important to be compatible if possible with existing client software (I'm not saying that just to be self-serving of course).
Personally I think (for what it's worth) the safest thing is to ignore dateTime.iso8601 values and assume new posts are created with the current date and time...that will annoy some people some of the time, but it will exactly fit the user's intention the vast majority of the time.
Friday, September 30, 2005 12:13:03 AM (GMT Daylight Time, UTC+01:00)
Dare: I don't think the TZ thing is actually broken... it just implies that every XML-RPC API should include some sort a getTimeZone() method. I have no idea why Dave never pushed to add such a method in the MW API, but it would clear up a lot of confusion.

Do us all a favor and add a msnGetTimeZone() method or something. A few of the client apps will pick it up, and maybe it'll get traction. That's one extension I'd be happy to support on the server.
Friday, September 30, 2005 1:23:45 AM (GMT Daylight Time, UTC+01:00)
I disagree. Forcing every implementation of an XML-RPC API to implement a particular method seems more onerous and prone to error than just specifying that datatype libraries used by XML-RPC support timezones.

PS: As for extending the MetaWeblog API, I don't intend for us to do anything beyond what is required to interop with existing clients at the current time.
Friday, September 30, 2005 3:52:45 AM (GMT Daylight Time, UTC+01:00)
Hmmm, you must of seen some other peoples rants on the metaweblog api before you started in on it, i can't believe this has come as a suprise to you.
Friday, September 30, 2005 9:33:46 AM (GMT Daylight Time, UTC+01:00)
Simon: I suppose now would be a bad time for me to bring up what's wrong with metaWeblog.getRecentPosts? (to be fair, the other blog engines have the same problem...but I really, really wish someone had thought to create a metaWeblog.listRecentPosts method).
Sunday, October 23, 2005 7:40:06 AM (GMT Daylight Time, UTC+01:00)
what the spec says about timezone is just weird to me.

You might be interested in reading this post below(comments).

Developers of blog clients(ecto for mac,ecto for windows,BlogWrite) are talking the same thing.

I think sending UTC is the best option right now.

PS. by the way, what happend to the beta tesing I signed up? it's been several month already. Hope you haven't to forgotten.

Toru Marumoto
Comments are closed.