On 23. Jun 2007, at 20:40, Steven W Riggins wrote:
I just installed WP 2.2.1 with Daniel Jalkut's xml-rpc changes but now I can't fetch posts at all due to an iso timecode error.
Hi Steven - I just signed up the list so I could reply :)
First of all, the 2.2.1 release of WordPress includes several fixes to XML-RPC that I encouraged, but Joseph did all the hard work. So they're not "my changes," but I do have some perspective on them.
The time-zone one you're running into is actually the earliest issue of the bunch that I raised, so it's not completely fresh in my memory. But it was motivated by a change in 2.2 that would cause the time zone to be completely omitted from the timestamps. While this is arguably correct by "the letter of the law" for XML-RPC, it's not something that WordPress had ever done before, so it threw off the times for posts in at least WordPress, and probably other clients as well.
I think the way it worked before 2.2 was to put the actual time zone of the blog into the timestamps. So if you had set your blog up as a -4 hours time zone, it would return dates with "-0400" or something on it. So with the change in 2.2 to represent dates in GMT format, I suggested that at least it should indicate as much so that the date would be unambiguous. I think I suggested using -0000, but since Z worked for me and seemed more satisfactory to Joseph, I had no objection.
Hope this helps clarify the rationale for the fixes. I'm not sure what Joseph should do at this point, if anything. Unless somebody can say with confidence that they feel -0000 will be more reliable across the most clients than Z is.
Daniel
I mean to say "in at least MarsEdit, and probably other clients as well."
On Jun 23, 2007, at 4:54 PM, Daniel Jalkut wrote:
While this is arguably correct by "the letter of the law" for XML- RPC, it's not something that WordPress had ever done before, so it threw off the times for posts in at least WordPress, and probably other clients as well.
On 23. Jun 2007, at 22:54, Daniel Jalkut wrote:
[...] The time-zone one you're running into is actually the earliest issue of the bunch that I raised, so it's not completely fresh in my memory. But it was motivated by a change in 2.2 that would cause the time zone to be completely omitted from the timestamps. While this is arguably correct by "the letter of the law" for XML-RPC, it's not something that WordPress had ever done before
Not being a WP hacker, so I might be wrong, but the change was not the actual TZ info, WP never sent such info.
The change was that now WP interprets all dates sent and received via XML-RPC as being in GMT. Previously they would be interpreted as server time, GMT offset specified in the admin settings, or GMT, depending on various variables which I could never fully grasp (from analyzing the code).
For that reason the TM blogging bundle never sent WP any dates unless you explicitly asked it to (since dates were not reliable unless you ensured everything was in GMT).
so it threw off the times for posts in at least WordPress, and probably other clients as well.
The only way the change in 2.2 would throw off previously correct dates was, if the program which displayed that date knew the server time / user settings on the server -- but since that depends on the server, the user would have to tell the client about it. So now the user just needs to update this info to say the server runs in GMT. I.e. I don’t see this breaking old stuff.
I think the way it worked before 2.2 was to put the actual time zone of the blog into the timestamps. So if you had set your blog up as a -4 hours time zone, it would return dates with "-0400" or something on it.
It did send a time which was the local time of the blog, but it *did not* give any TZ info.
So with the change in 2.2 to represent dates in GMT format, I suggested that at least it should indicate as much so that the date would be unambiguous. I think I suggested using -0000, but since Z worked for me and seemed more satisfactory to Joseph, I had no objection.
Dates were ambiguous prior to the change. I agree though that the Z is nice because it clarifies that this date is in GMT, unfortunately not all XML-RPC parsers will support it (e.g. not the one in Ruby 1.8.2), and the XML-RPC specification indicates that the TZ is outside the actual XML-RPC transportation layer and should be documented by the server/protocol -- in our case that would be the MetaWeblog API, which is a worse specification than the XML-RPC spec. itself, and of course does not document anything related to time zone.
But the consensus among blogging software does seem to be that dates are in GMT (and prior to WP 2.2, WP was the oddball).
Hope this helps clarify the rationale for the fixes. I'm not sure what Joseph should do at this point, if anything. Unless somebody can say with confidence that they feel -0000 will be more reliable across the most clients than Z is.
The best is really to not send any TZ info as -0000 will still break some XML-RPC parsers.
Thanks Daniel,
Thats what you get for getting credit! :)
At least its understood why it was done this way. I find it humorous that its 2007 and there is no standard format for time, I mean in the sense of a "duh, of course its done this way" Like writing hello world :) Oh wait.......
Hi Allan -
On Jun 23, 2007, at 5:26 PM, Allan Odgaard wrote:
Not being a WP hacker, so I might be wrong, but the change was not the actual TZ info, WP never sent such info.
Yeah that is ringing a bell. I guess my memory was as rusty as I feared :)
The best is really to not send any TZ info as -0000 will still break some XML-RPC parsers.
The problem I have with this is, how do I tell that the server is a WordPress that returns ambiguous dates that happen to be GMT vs ambiguous dates that happen to be blog-local time?
It seems like a good idea that, associated with the change in behavior, there should be some change in notation.
It's a shame that the time zone info breaks parsers, since it's all part of standard ISO8601 date format.
Daniel
Thats what you get for getting credit! :)
haha!
At least its understood why it was done this way. I find it humorous that its 2007 and there is no standard format for time, I mean in the sense of a "duh, of course its done this way" Like writing hello world :) Oh wait.......
I guess Allan's reply reveals that it's not 100% understood all around why it's done the way it is, but there were good motivations at least :)
The thing is there IS a standard format for time, which is the format that is being used here (the Z and -0000 type extensions are all part of ISO8601, which I believe is specified as the date format for XML- RPC). The problems here seem to be dealing with historical mistakes in how those standard dates were used in WordPress.
D
I say we fix the parsers. Upgrading to the most recent ruby worked and while not for the non-geek, neither is TextMate really :)
Other apps can fix their bugs as needed.
I'm a big fan of fixing bugs the right way and not hacking solutions to make things work.
On Jun 23, 2007, at 2:42 PM, Daniel Jalkut wrote:
It's a shame that the time zone info breaks parsers, since it's all part of standard ISO8601 date format.
On 23. Jun 2007, at 23:44, Daniel Jalkut wrote:
At least its understood why it was done this way. I find it humorous that its 2007 and there is no standard format for time, I mean in the sense of a "duh, of course its done this way" Like writing hello world :) Oh wait.......
[...] The thing is there IS a standard format for time, which is the format that is being used here (the Z and -0000 type extensions are all part of ISO8601, which I believe is specified as the date format for XML-RPC).
I don’t really agree here. The only indication of ISO 8601 in the [specification][1] is that it is part of the name.
But I think this is because the person who did the specification thought that ISO 8601 was limited to dates of the form 19980717T14:08:55 (which is his example).
According to ISO 8601 our current date can be expressed as +002007W256 -- does MarsEdit understand that? :)
For anyone interested, the full spec can be [found here][2]. Only 40 pages, but then it also defines time intervals and reoccurring time intervals :) Of course the “datetime” prefix given to ISO8601 in the XML-RPC spec could mean that it is only the date + time profiles which are allowed (yet, there are still a few of these, and the above is a “week date” in extended form which can be combined with a representation of time of day and form a date + time).
[1]: http://www.xmlrpc.com/spec [2]: http://isotc.iso.org/livelink/livelink/4021199/ ISO_8601_2004_E.zip?func=doc.Fetch&nodeid=4021199
Ah yes - good point. Touché :)
You actually reminded me of a headache I had to deal with when some service suddenly started adding milliseconds precision to their dates.
Indeed, MarsEdit's date parsing consists of a fixed set of templatized formats that manage to cover most of the blogging systems' habits.
Daniel
On Jun 23, 2007, at 6:44 PM, Allan Odgaard wrote:
According to ISO 8601 our current date can be expressed as +002007W256 -- does MarsEdit understand that? :)
On Jun 23, 2007, at 3:55 PM, Daniel Jalkut wrote:
Ah yes - good point. Touché :)
You actually reminded me of a headache I had to deal with when some service suddenly started adding milliseconds precision to their dates.
Indeed, MarsEdit's date parsing consists of a fixed set of templatized formats that manage to cover most of the blogging systems' habits.
Daniel
On Jun 23, 2007, at 6:44 PM, Allan Odgaard wrote:
According to ISO 8601 our current date can be expressed as +002007W256 -- does MarsEdit understand that? :)
Can we move this discussion to new wp-xmlrpc list (http:// lists.automattic.com/mailman/listinfo/wp-xmlrpc) ?
I want to make things work for as many people as possible, but it is getting difficult to not break someone as these tweaks go forward.
Allan, will you post to the wp-xmlrpc list itemizing the exact issues as they currently stand, then perhaps some of the other xml-rpc folks on the list can chime in.
-- Joseph Scott http://joseph.randomnetworks.com/
-
Allan Odgaard -
Daniel Jalkut -
Joseph Scott -
Steven W Riggins