[wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2

[Allan Odgaard]

On 26. Jun 2007, at 22:28, Joseph Scott wrote:

> [...]
> Ok.  It isn't great, but if we can combined the revert with the new  
> solution then we should be able to make most people happy.  I'd  
> like to hear what Allan has to say on this as well.

Okay, I think there is consensus about removing the Z suffix, so I  
won’t comment further on that.

Below is my summary of the situation listing pros and cans of how to  
clarify the TZ of `dateCreated`.

Given the current feedback I would okay a change that reverts the  
`dateCreated` to pre-2.2 and sends the blog’s TZ offset as an  
additional field expressed as the minutes since UTC (given as  
`<int>`), I give additional info after the following summary.

First, the two ways in which we can clarify the TZ:

  1. **Documentation**

     Consensus among blog servers is to treat dates as being in the
     blog’s time zone.

     Consensus among desktop clients is to treat dates as being in the
     user’s time zone.

     This works when the user ensures that the two are in sync but in
     addition to requiring mandatory setup it neglects to deal with:

       * Multiple persons from different time zones posting to the
         same blog.

       * People who physically move to another time zone (or
         traveling) -- this would require them to update their blog’s
         time zone preferences to reflect their new local time zone,
         but this will likely affect the displayed time of all
         previous posts (in addition to being tedious).

       * Daylight savings -- should the desktop client subtract a
         potential daylight savings offset from the date or expect the
         blog time to also be adjusted for daylight savings?

       * Users who do not want their blog to be in their local time
         zone.

     Agreeing on a TZ (like UTC) which both the server and the client
     knows the dates are in, would solve the problem *but* the status
     quo does work “good enough” for many users, where moving to an
     agreed upon time zone will introduce a transition period where
     users need to update both their desktop and server software, to
     again have correct dates (assuming we get everyone onboard on
     mandating UTC as the TZ used).

  2. **Auxiliary Fields**

     To avoid a problematic transition period (where only one end has
     been updated to work with UTC dates) one can augment the current
     MetaWeblog API to specify TZ info and thus keep the current
     (unspecified) TZ behavior for `dateCreated`. This means for users
     where it worked, it keeps working, and for users where it did
     not, they would still need to update their software.

     A few solutions for how to augment it has been proposed:

      * Introduce a replacement for `<dateTime.iso8601>` to the
        XML-RPC specification. Disadvantage: Will be tedious (if at
        all possible) to handle by users of off-the-shelves XML-RPC
        libraries.

      * Provide the TZ part as an extra field. This can be done in two
        ways:

         1. Something you append to `dateCreated` and then parse it as
            a date with TZ info. The disadvantage is the same as with
            introducing a replacement for the `<dateTime.iso8601>`
            type, i.e. difficult to handle with existing XML-RPC
            parsers.

         2. Provide the offset (in minutes) as an additional `<int>`
            value. This should generally be easy to handle.

      * Introduce a `dateCreatedUTC` or similar field. This has
        similar ease-of-use as providing the numerical offset and
        would be documented to take precedence over `dateCreated`, so
        any discrepancy can safely be ignored.

After a somewhat objective summary, my personal opinion is:

Current “consensus” around `dateCreated` is broken and documenting it  
as being UTC makes a currently fragile date robust and avoids adding  
complexity to the specification (i.e. new fields).

But if we want a smoother transition, at the cost of adding new  
fields to the standard, I would prefer the offset (specified with  
`<int>`) over having two date fields.

The reason is that I perceive it slightly simpler to implement (both  
for sending and receiving). I base this on the fact that with  
`dateCreated` + `dateCreatedUTC` you will need code to handle two  
variations of a date, where with `dateCreated` + offset, you always  
handle the same date field, and when the offset is missing, you just  
set it to the users local TZ offset (and use the same code).