[wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2

[Joe Cheng]

> So specifying a time zone in the dateCreated field (e.g. as Windows
> Live Spaces does and WordPress does in 2.2.1) would oblige the
> server to leave dateCreatedTimeZone *empty* so that appending would
> cause no change to the fully-qualified time.

I'd also be fine with saying that servers that do the Z need to repeat
the Z in the dateCreatedTimeZone. Although now that we're back to
repeating ourselves, what happens if there is a Z in dateCreated but
a non-Z value in dateCreatedTimeZone?

And I'd also be fine with saying that servers that do the Z must not
include a dateCreatedTimeZone at all. Clients would already need to
test for the presence/absence of dateCreatedTimeZone; if we make it
meaningful/valid for dateCreatedTimeZone to have an empty value, then
that's an additional check which would be nice to avoid.

I don't feel too strongly about it in any case. As previously discussed
in this thread, servers that care about compatibility at all should
not be adding Z to dateCreated (or any other XML-RPC date/time value)
so hopefully this won't be a common case.

Actually, screw it--why shouldn't we prescribe exactly what the behavior
should be? Do server implementers really want flexibility here?? "The
dateCreated MUST be in exactly yyyyMMddTHH:mm:ss format and SHOULD
reflect the blog's local time zone if possible, and dateCreatedTimeZone
MUST specify the offset or Z if UTC." <= for getPost and getRecentPost
only--there's different de facto behavior for newPost and editPost.