[wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2

[Joseph Scott]

On Jun 26, 2007, at 12:04 PM, Daniel Jalkut wrote:

> On Jun 26, 2007, at 2:58 PM, Joe Cheng wrote:
>
>> 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.
>
> Sounds good to me. I agree it would be good to push servers to get  
> rid of the Z from the dateCreated field since we know it breaks  
> clients.
>
> Fulfilling the "disambiguation" through an additional, newly  
> defined XML attribute seems like a good path to continue pursuing.  
> And I agree with you that now we've got some decent ideas on the  
> table we should wait for Joseph and/or other WP peeps to chime in.
>
> Thanks for brainstorming this with me,


Sorry about the delay in replying to this thread, I'm in the middle  
of moving from California to Utah and things are a bit crazy around  
here.

Ok, so I've read through all of these messages and I hopefully have a  
grasp of where we stand.  If we broke something with WordPress 2.2.1  
with a (large?) number of clients lets fix that first.  Even if it  
mean a small step backwards.

In going over the changes in the 2.2 branch for xmlrpc.php (http:// 
trac.wordpress.org/log/branches/2.2/xmlrpc.php) revision 5305 (and  
5514 by association) is where the problem hit.  So reverting 5305 in  
the 2.2 branch (and trunk, along with the associated 5514 revision)  
will fix the client breakage.  Does everyone agree this is correct?

Now, this puts us back in the rather unpleasant spot of time zone  
madness.  I will gladly agree that the specs here are worse than  
useless, but I'll save the rant for another time.  How do we go  
forward from here.  The two options that have been brought thus far  
are to:

1) add a new field that explicitly provides the GMT date/time of the  
post
2) add a new field that provides the time zone offset

My gut feeling is to support option 1, spelling out exactly what the  
format MUST be (yyyyMMddThh:mm:ssZ) for that field and that anything  
that does match that exactly is completely bogus.  However, I don't  
have a problem going with option 2 as long as we can provide a  
similarly strong requirement for the format of the data.  I don't  
claim to be a time zone guru, but I do know that there are some funky  
time zone offsets out there.  My concern would be that the potential  
values in the offset field would be uglier that just providing the  
explicit GMT value of the date.

I don't have a problem going with either option as long as it:

A) breaks as few clients, parsers, etc as possible; ideally none of  
course :-)
B) is the option least likely to cause any future confusion
C) reasonable/easy/helpful for clients to support (this one is kind  
of fuzzy)



--
Joseph Scott
http://joseph.randomnetworks.com/