From m at mullenweg.com Wed Jun 20 07:22:01 2007 From: m at mullenweg.com (Matt Mullenweg) Date: Wed, 20 Jun 2007 00:22:01 -0700 Subject: [wp-xmlrpc] Lack of buzzwords Message-ID: <4678D599.8030009@mullenweg.com> I get the impression that "XML" and "RPC" aren't enough. Can we work Ajax and Comet in there somehow? -- Matt Mullenweg http://photomatt.net | http://wordpress.org http://automattic.com | http://akismet.com From jalkut at red-sweater.com Wed Jun 20 14:03:29 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Wed, 20 Jun 2007 10:03:29 -0400 Subject: [wp-xmlrpc] Lack of buzzwords In-Reply-To: <4678D599.8030009@mullenweg.com> References: <4678D599.8030009@mullenweg.com> Message-ID: <52F4314A-A068-43D8-83A2-92473700CE58@red-sweater.com> Nice way of testing the list out :) But I think it raises an interesting question. Should the buzzword "Atom" fall under the umbrella of this list? Daniel On Jun 20, 2007, at 3:22 AM, Matt Mullenweg wrote: > I get the impression that "XML" and "RPC" aren't enough. Can we work > Ajax and Comet in there somehow? > > -- > Matt Mullenweg > http://photomatt.net | http://wordpress.org > http://automattic.com | http://akismet.com > _______________________________________________ > wp-xmlrpc mailing list > wp-xmlrpc at lists.automattic.com > http://lists.automattic.com/mailman/listinfo/wp-xmlrpc From jcaustin87 at gmail.com Mon Jun 25 18:08:33 2007 From: jcaustin87 at gmail.com (John Austin) Date: Mon, 25 Jun 2007 13:08:33 -0500 Subject: [wp-xmlrpc] WP 2.2.1 with TextMate Message-ID: <35282C3D-5D5A-463E-8E4F-98FCB0FFD35E@gmail.com> What is the status on a fix for the fetch function of TextMate and WP 2.2.1? I'll admit this is my first time on the list so I've missed a fix, please forgive. Would like to get this resolved so that I can keep using textmate exclusively for my blog. Thanks. John From joseph at randomnetworks.com Mon Jun 25 22:19:44 2007 From: joseph at randomnetworks.com (Joseph Scott) Date: Mon, 25 Jun 2007 15:19:44 -0700 Subject: [wp-xmlrpc] WP 2.2.1 with TextMate In-Reply-To: <35282C3D-5D5A-463E-8E4F-98FCB0FFD35E@gmail.com> References: <35282C3D-5D5A-463E-8E4F-98FCB0FFD35E@gmail.com> Message-ID: <21581CD6-9395-4D20-87CC-D95ACFEC688A@randomnetworks.com> On Jun 25, 2007, at 11:08 AM, John Austin wrote: > What is the status on a fix for the fetch function of TextMate and > WP 2.2.1? > > I'll admit this is my first time on the list so I've missed a fix, > please forgive. Would like to get this resolved so that I can keep > using textmate exclusively for my blog. I believe this is the timezone issue that the older Ruby libraries have. The best thing seems to be updating to a newer version that doesn't choke on the timezones. I'm trying to get that thread/conversation to move here so we can discuss the options going forward at this point. -- Joseph Scott http://joseph.randomnetworks.com/ From m at mullenweg.com Tue Jun 26 01:52:18 2007 From: m at mullenweg.com (Matt Mullenweg) Date: Mon, 25 Jun 2007 18:52:18 -0700 Subject: [wp-xmlrpc] Lack of buzzwords In-Reply-To: <52F4314A-A068-43D8-83A2-92473700CE58@red-sweater.com> References: <4678D599.8030009@mullenweg.com> <52F4314A-A068-43D8-83A2-92473700CE58@red-sweater.com> Message-ID: <46807152.6060900@mullenweg.com> Daniel Jalkut wrote: > Nice way of testing the list out :) But I think it raises an interesting > question. > > Should the buzzword "Atom" fall under the umbrella of this list? Yes! You may notice that both Atom and XML-RPC have the letter M, so I think both publishing protocols fall under the purview of this nascent discussion area. -- Matt Mullenweg http://photomatt.net | http://wordpress.org http://automattic.com | http://akismet.com From jcaustin87 at gmail.com Tue Jun 26 03:59:50 2007 From: jcaustin87 at gmail.com (John Austin) Date: Mon, 25 Jun 2007 22:59:50 -0500 Subject: [wp-xmlrpc] WP 2.2.1 with TextMate In-Reply-To: <21581CD6-9395-4D20-87CC-D95ACFEC688A@randomnetworks.com> References: <35282C3D-5D5A-463E-8E4F-98FCB0FFD35E@gmail.com> <21581CD6-9395-4D20-87CC-D95ACFEC688A@randomnetworks.com> Message-ID: Forgive me for being somewhat niaive but how would one go about updating their ruby? john jaustin.cc On Jun 25, 2007, at 5:19 PM, Joseph Scott wrote: > > On Jun 25, 2007, at 11:08 AM, John Austin wrote: > >> What is the status on a fix for the fetch function of TextMate and >> WP 2.2.1? >> >> I'll admit this is my first time on the list so I've missed a fix, >> please forgive. Would like to get this resolved so that I can keep >> using textmate exclusively for my blog. > > I believe this is the timezone issue that the older Ruby libraries > have. The best thing seems to be updating to a newer version that > doesn't choke on the timezones. > > I'm trying to get that thread/conversation to move here so we can > discuss the options going forward at this point. > > > -- > Joseph Scott > http://joseph.randomnetworks.com/ > > > _______________________________________________ > wp-xmlrpc mailing list > wp-xmlrpc at lists.automattic.com > http://lists.automattic.com/mailman/listinfo/wp-xmlrpc From joseph at randomnetworks.com Tue Jun 26 04:04:19 2007 From: joseph at randomnetworks.com (Joseph Scott) Date: Mon, 25 Jun 2007 21:04:19 -0700 Subject: [wp-xmlrpc] WP 2.2.1 with TextMate In-Reply-To: References: <35282C3D-5D5A-463E-8E4F-98FCB0FFD35E@gmail.com> <21581CD6-9395-4D20-87CC-D95ACFEC688A@randomnetworks.com> Message-ID: <647E355B-B870-49E5-8042-ED80049A5137@randomnetworks.com> On Jun 25, 2007, at 8:59 PM, John Austin wrote: > Forgive me for being somewhat niaive but how would one go about > updating their ruby? Below is an email from Allan Odgaard on the subject. ------------------------- > 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. > The problem is that now WP will send the date as ‘YYYYMMDDTHH:MM:SSZ’. Previously it would not send the trailing ‘Z’ and ruby 1.8.2 (shipped with Tiger) does *not* expect that ‘Z’ (and thus raises a “wrong format” exception). The XML-RPC specification defines the format using one example which is w/o a ‘Z’ (and there is an additional note about time zone info which hints that they did not expect this type to ever carry TZ info [1]) so WP is probably wrong in sending it. That said, newer versions of Ruby’s XML-RPC parser do support several variations, so upgrading your Ruby [2] will fix the problem -- but I have cc’ed Joseph, he can say if we should expect a patch for WP. [1] Which is unbelievable stupid, but that whole spec is unbelievable stupid. [2] Remember to update “shebang path” -- http://macromates.com/ textmate/manual/shell_commands#search_path ------------------------- -- Joseph Scott http://joseph.randomnetworks.com/ From jcaustin87 at gmail.com Tue Jun 26 04:26:45 2007 From: jcaustin87 at gmail.com (John Austin) Date: Mon, 25 Jun 2007 23:26:45 -0500 Subject: [wp-xmlrpc] WP 2.2.1 with TextMate In-Reply-To: <647E355B-B870-49E5-8042-ED80049A5137@randomnetworks.com> References: <35282C3D-5D5A-463E-8E4F-98FCB0FFD35E@gmail.com> <21581CD6-9395-4D20-87CC-D95ACFEC688A@randomnetworks.com> <647E355B-B870-49E5-8042-ED80049A5137@randomnetworks.com> Message-ID: <827AF850-CB42-40C2-9935-5D4273106193@gmail.com> Well that was the easiest quick fix that I have ever done. On Jun 25, 2007, at 11:04 PM, Joseph Scott wrote: > > On Jun 25, 2007, at 8:59 PM, John Austin wrote: > >> Forgive me for being somewhat niaive but how would one go about >> updating their ruby? > > Below is an email from Allan Odgaard on the subject. > ------------------------- > >> 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. >> > > The problem is that now WP will send the date as ‘YYYYMMDDTHH:MM:SSZ’. > > Previously it would not send the trailing ‘Z’ and ruby 1.8.2 > (shipped with Tiger) does *not* expect that ‘Z’ (and thus raises a > “wrong format” exception). > > The XML-RPC specification defines the format using one example > which is w/o a ‘Z’ (and there is an additional note about time zone > info which hints that they did not expect this type to ever carry > TZ info [1]) so WP is probably wrong in sending it. > > That said, newer versions of Ruby’s XML-RPC parser do support > several variations, so upgrading your Ruby [2] will fix the problem > -- but I have cc’ed Joseph, he can say if we should expect a patch > for WP. > > > [1] Which is unbelievable stupid, but that whole spec is > unbelievable stupid. > [2] Remember to update “shebang path” -- http://macromates.com/ > textmate/manual/shell_commands#search_path > > ------------------------- > > > > -- > Joseph Scott > http://joseph.randomnetworks.com/ > > > _______________________________________________ > wp-xmlrpc mailing list > wp-xmlrpc at lists.automattic.com > http://lists.automattic.com/mailman/listinfo/wp-xmlrpc From m123ixd02 at sneakemail.com Tue Jun 26 05:10:12 2007 From: m123ixd02 at sneakemail.com (Allan Odgaard) Date: Tue, 26 Jun 2007 07:10:12 +0200 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 Message-ID: <17596-17653@sneakemail.com> WP 2.2.1 adds a ‘Z’ to the dates sent to stress that the time is in GMT. This is not explicitly allowed by the standard [1] and while the date remains a valid ISO 8601 date, I do not think that the intent of the standard is to allow all valid ISO 8601 dates (see [2] for elaboration). Ruby 1.8.2, which is what is included with Apple’s Mac OS X 10.4.x, has an XML-RPC parser which does not expect this ‘Z’ and will in fact throw an exception if it encounters one. So the dilemma is: should WP go beyond the XML-RPC standard and explicitly state the time zone, effectively breaking some XML-RPC parsers, or should it send a date without time zone info (as done in the past). The XML-RPC standard says the time zone should be documented by the server, and to the best of my knowledge, other blogging systems (which implement the MetaWeblog API) are treating dates as being in GMT (IMO the only thing that makes sense when the producer of the date is not running on the same system as the consumer). So my recommendation would be to revert the change in WP 2.2.1 that added the ‘Z’ to dates. Long-term my recommendation is to revise both the XML-RPC and MetaWeblog standards! ;) [1]: http://www.xmlrpc.com/spec [2]: http://lists.macromates.com/pipermail/textmate/2007-June/ 020583.html From m123ixd02 at sneakemail.com Tue Jun 26 05:46:26 2007 From: m123ixd02 at sneakemail.com (Allan Odgaard) Date: Tue, 26 Jun 2007 07:46:26 +0200 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <17596-17653@sneakemail.com> References: <17596-17653@sneakemail.com> Message-ID: <26669-72708@sneakemail.com> On 26. Jun 2007, at 07:10, Allan Odgaard wrote: > [...] > Ruby 1.8.2, which is what is included with Apple’s Mac OS X 10.4.x, > has an XML-RPC parser which does not expect this ‘Z’ and will in > fact throw an exception if it encounters one. I should add that while newer versions of Ruby will support dates with TZ info, there are still many implementations of an XML-RPC parser which will not, e.g. http://xmlrpc-c.sourceforge.net/ linked to from xmlrpc.com. From jalkut at red-sweater.com Tue Jun 26 14:11:43 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 10:11:43 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <17596-17653@sneakemail.com> References: <17596-17653@sneakemail.com> Message-ID: On Jun 26, 2007, at 1:10 AM, Allan Odgaard wrote: > So my recommendation would be to revert the change in WP 2.2.1 that > added the ‘Z’ to dates. If this reversion of behavior is done, it's only fair that it reverts all the way to pre2.2 behavior, where the date was sent in the time zone of the *blog* and not GMT. The issue here is that all changes are breaking *somebody*. I think we should either swallow the medicine and take a fully qualified date (with time zone information), or go back to the stone ages to maximize compatibility with all existing clients (because they had built-in this assumption that no-time-zone from WordPress means "blog time"). Daniel From m123ixd02 at sneakemail.com Tue Jun 26 14:41:33 2007 From: m123ixd02 at sneakemail.com (Allan Odgaard) Date: Tue, 26 Jun 2007 16:41:33 +0200 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> Message-ID: <10622-65514@sneakemail.com> On 26. Jun 2007, at 16:11, Daniel Jalkut wrote: > On Jun 26, 2007, at 1:10 AM, Allan Odgaard wrote: >> So my recommendation would be to revert the change in WP 2.2.1 >> that added the ‘Z’ to dates. > If this reversion of behavior is done, it's only fair that it > reverts all the way to pre2.2 behavior, where the date was sent in > the time zone of the *blog* and not GMT. Not sure why you would push for such a change. Do we agree that with such behavior, the user will need to explicitly configure his client with the time zone of his blog? It seems like a terrible idea to introduce such configuration step. From jalkut at red-sweater.com Tue Jun 26 14:52:58 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 10:52:58 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <10622-65514@sneakemail.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> Message-ID: On Jun 26, 2007, at 10:41 AM, Allan Odgaard wrote: >> If this reversion of behavior is done, it's only fair that it >> reverts all the way to pre2.2 behavior, where the date was sent in >> the time zone of the *blog* and not GMT. > > Not sure why you would push for such a change. > > Do we agree that with such behavior, the user will need to > explicitly configure his client with the time zone of his blog? > > It seems like a terrible idea to introduce such configuration step. I'm not pushing for a change - I'm pushing (sort of) for "the way things used to be." If we're going to make the effort of reverting back to a "non-breaking" behavior, then I propose we go all the way back to pre2.2 (a behavior that will match the functionality for many people who have yet to upgrade to 2.2 and are doing so gradually over time). Of course the current "Z" behavior is working fine for me so I'm also happy with sticking it out, but if we're going to selectively revert changes then I suggest it's not fair that WordPress changes now to fix PHP but to break MarsEdit (and possibly other clients). The timeline here: Pre2.2: Everything was "fine" for some definition of "fine." Probably things should be evolved but slowly and in a way that clients can adapt to. 2.2: Times switched to implicit GMT, throwing off the time expectations of MarsEdit (and probably other clients). 2.2.1: Times switched to explicit GMT, throwing off the parsers in Ruby (and probably other clients). While you seem to be suggesting that the solution is to go back to 2.2, I'm suggesting the solution is either to go back to Pre2.2, or come up with a more ingenious solution. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From m123ixd02 at sneakemail.com Tue Jun 26 15:36:40 2007 From: m123ixd02 at sneakemail.com (Allan Odgaard) Date: Tue, 26 Jun 2007 17:36:40 +0200 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> Message-ID: <9534-28958@sneakemail.com> On 26. Jun 2007, at 16:52, Daniel Jalkut jalkut-at-red-sweater.com | WP XML-RPC| wrote: > [...] > I'm not pushing for a change - I'm pushing (sort of) for "the way > things used to be." If we're going to make the effort of reverting > back to a "non-breaking" behavior, then I propose we go all the way > back to pre2.2 (a behavior that will match the functionality for > many people who have yet to upgrade to 2.2 and are doing so > gradually over time). Pre 2.2 was broken! It did not work! It may have worked for you because you have your blog in your local time zone AND you have a client that interprets dates as being in the local time zone. But this is definitely not “working” by my definition. What if you take your laptop with you on vacation a place where you are not in that time zone anymore? Not everyone has their blog in their local time zone, and even those who have, doesn’t have it all the time. > Of course the current "Z" behavior is working fine for me so I'm > also happy with sticking it out, but if we're going to selectively > revert changes then I suggest it's not fair that WordPress changes > now to fix PHP but to break MarsEdit (and possibly other clients). WP introduced something which a) breaks *several* XML-RPC parsers and b) is *not* explicitly allowed by the standard. But because it does not break your program, then it is fine? I wish you would show more interest in having WP adhere to established standards rather than just make it work with your software :/ > The timeline here: > > Pre2.2: Everything was "fine" for some definition of "fine." > Probably things should be evolved but slowly and in a way that > clients can adapt to. How were things fine? Are you saying that if I install WP 2.1 + MarsEdit and fetch posts from my blog, these will show the proper dates (hint, my blog does not run in CET / CEST)? > 2.2: Times switched to implicit GMT, throwing off the time > expectations of MarsEdit (and probably other clients). But things were already broken -- just not with your setup. But your expectations (that the blog time is the local time) is wrong! > 2.2.1: Times switched to explicit GMT, throwing off the parsers in > Ruby (and probably other clients). And definitely others, as I wrote, the C/C++ parser linked to from XML-RPC.com also expect the format specified in the spec. and will barf at anything but that format. > While you seem to be suggesting that the solution is to go back to > 2.2, I'm suggesting the solution is either to go back to Pre2.2, or > come up with a more ingenious solution. Yes, I figured that much, but it seems rather selfish and shortsighted, because pre 2.2 did not work for everybody, and there was really no way for it to work for everybody (at least not w/o user interaction wrt setting time zone info). Is it wrong if I say your motivation for not wanting 2.2 behavior is that you don’t want those MarsEdit users who do not upgrade their WP, and do have it running in the same TZ as their own machine, to see a wrong date? Because both pre-2.2 and post-2.2 are solutions with clear flaws, so I really can’t see why you’d want either of these two over 2.2 which a) conforms to the XML-RPC standard (unlike 2.2.1) and b) gives dates which can be made to work out-of-the-box for everybody (unlike pre-2.2). And really, if you are concerned about MarsEdit users with a pre-2.2 WP install, introduce a (hidden) option to indicate that blog time is local time (though better, allow the blog’s TZ to be specified, as the other is not a solution for everyone, as I have repeatedly argued). From jalkut at red-sweater.com Tue Jun 26 16:38:05 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 12:38:05 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <9534-28958@sneakemail.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> Message-ID: <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> Allan - I think we each are probably looking at this issue with some degree of "blindness" to the other's position. I'm trying to rectify that now, and taking a closer look at the behavior of other blog systems to see how they compare to WP. But I don't think the accusatory tone is helping anything. You allude repeatedly to my motivations in this debate being selfish or only interested in having things work for my product. While it's true that I am more acutely aware of how the changes impact my product, it's unfair to repeatedly draw the conclusion that therefore I'm not interested in standards or not interested in choosing a solution that works well for everybody. That implication is simply not consistent with the way I behave or my track record for working cooperatively with other people. If I've said anything unfactual it's out of ignorance and not any selfish malice. My motivations in arguing for the pre-2.2 behavior were largely "because it was that way, and you're breaking me," it's true. But that's a legitimate reaction to changing behavior that causes a bug! (I didn't realize at the time that it may have been a change specifically motivated by your efforts to FIX a bug). The thing is, when it comes to these blogging systems and the XML-RPC standard to which they supposedly comply, it's often *much* more informative to look out at the landscape of blogging systems to see what people are *doing* instead of what they're supposed to do. So what happens in the real world, on a number of real XML-RPC supporting systems, when I just send a post NOW without a specific date attached? A test MovableType blog on my system, with a time zone setting of GMT-0500, when sent a new post with no date a few minutes ago, returns the post with the created date: "20070626T12:12:13". That is, it's returning my local time. If I change the time zone to match GMT, what happens? The time *still* comes back as my local time. So my assumption here is that the MT server is returning its server time instead of GMT time or GMT-adjusted-for-blog-time. But it's *not* returning GMT time, either. On to Drupal - given a similar test, with the time zone this time set to GMT, it returns an identically schemed date created of "20070626T12:23:04" (some time has passed since my first test). Again - it's returning the *machine* time. Not a great solution by any means, but consistent with MovableType. Windows Live Spaces? It supports the MetaWeblog XML-RPC interface. It breaks from the pack here and returns a time in GMT but *with* the Z that we're fiercely debating here: 2007-06-26T16:28:07Z. LiveJournal's Blogger interface uses the Blogger variant of the XML- RPC interface, it also seems to be doing the "server time zone" thing, returning an unqualified time corresponding to an hour ago: 20070626T11:30:00. Serendipity? 20070626T12:31:36. SquareSpace? 2007-06-26T12:32:27. How about WordPress? Before 2.2 it complied with a modified version of the "server time" ... but did the user the favor of letting them at least have a time-zone relevant version of the server time. Essentially it let users set the server time specific to their blog. In 2.2 it shifted to a behavior that is not shared with any other major blogging system that I know of or have tested. That is, representing the time as GMT without explicitly identifying it as such. In 2.2.1, as a compromise reaction to my request that it should go back to the way it was, Joseph added a "Z" to explicitly identify the time zone. This put it in the same boat as Microsoft Live Spaces which, I confess, is a pretty niche area to be in. My point? NONE of these systems uses an unadorned GMT-based time as their default time representation. Is it a major bug? Yes, perhaps. But you are painting me as some kind of villain because I want WordPress to behave "like all the others" at least to some extent. Unadorned GMT times are PARSEABLE by your parsers, perhaps. But they're semantically *meaningless* given the current state of de facto time "standards" (ugh, not even close) on the major (and minor, because they copy the majors) blog systems. Daniel On Jun 26, 2007, at 11:36 AM, Allan Odgaard wrote: > On 26. Jun 2007, at 16:52, Daniel Jalkut jalkut-at-red-sweater.com | > WP XML-RPC| wrote: > >> [...] >> I'm not pushing for a change - I'm pushing (sort of) for "the way >> things used to be." If we're going to make the effort of reverting >> back to a "non-breaking" behavior, then I propose we go all the >> way back to pre2.2 (a behavior that will match the functionality >> for many people who have yet to upgrade to 2.2 and are doing so >> gradually over time). > > Pre 2.2 was broken! It did not work! > > It may have worked for you because you have your blog in your local > time zone AND you have a client that interprets dates as being in > the local time zone. But this is definitely not “working” by my > definition. What if you take your laptop with you on vacation a > place where you are not in that time zone anymore? Not everyone has > their blog in their local time zone, and even those who have, > doesn’t have it all the time. > >> Of course the current "Z" behavior is working fine for me so I'm >> also happy with sticking it out, but if we're going to selectively >> revert changes then I suggest it's not fair that WordPress changes >> now to fix PHP but to break MarsEdit (and possibly other clients). > > WP introduced something which a) breaks *several* XML-RPC parsers > and b) is *not* explicitly allowed by the standard. But because it > does not break your program, then it is fine? > > I wish you would show more interest in having WP adhere to > established standards rather than just make it work with your > software :/ > >> The timeline here: >> >> Pre2.2: Everything was "fine" for some definition of "fine." >> Probably things should be evolved but slowly and in a way that >> clients can adapt to. > > How were things fine? Are you saying that if I install WP 2.1 + > MarsEdit and fetch posts from my blog, these will show the proper > dates (hint, my blog does not run in CET / CEST)? > >> 2.2: Times switched to implicit GMT, throwing off the time >> expectations of MarsEdit (and probably other clients). > > But things were already broken -- just not with your setup. But > your expectations (that the blog time is the local time) is wrong! > >> 2.2.1: Times switched to explicit GMT, throwing off the parsers in >> Ruby (and probably other clients). > > And definitely others, as I wrote, the C/C++ parser linked to from > XML-RPC.com also expect the format specified in the spec. and will > barf at anything but that format. > >> While you seem to be suggesting that the solution is to go back to >> 2.2, I'm suggesting the solution is either to go back to Pre2.2, >> or come up with a more ingenious solution. > > Yes, I figured that much, but it seems rather selfish and > shortsighted, because pre 2.2 did not work for everybody, and there > was really no way for it to work for everybody (at least not w/o > user interaction wrt setting time zone info). > > Is it wrong if I say your motivation for not wanting 2.2 behavior > is that you don’t want those MarsEdit users who do not upgrade > their WP, and do have it running in the same TZ as their own > machine, to see a wrong date? > > Because both pre-2.2 and post-2.2 are solutions with clear flaws, > so I really can’t see why you’d want either of these two over 2.2 > which a) conforms to the XML-RPC standard (unlike 2.2.1) and b) > gives dates which can be made to work out-of-the-box for everybody > (unlike pre-2.2). > > And really, if you are concerned about MarsEdit users with a > pre-2.2 WP install, introduce a (hidden) option to indicate that > blog time is local time (though better, allow the blog’s TZ to be > specified, as the other is not a solution for everyone, as I have > repeatedly argued). > > _______________________________________________ > wp-xmlrpc mailing list > wp-xmlrpc at lists.automattic.com > http://lists.automattic.com/mailman/listinfo/wp-xmlrpc > From jalkut at red-sweater.com Tue Jun 26 16:44:15 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 12:44:15 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> Message-ID: On Jun 26, 2007, at 12:38 PM, Daniel Jalkut wrote: > My point? NONE of these systems uses an unadorned GMT-based time as > their default time representation. Is it a major bug? Yes, perhaps. > But you are painting me as some kind of villain because I want > WordPress to behave "like all the others" at least to some extent. And to put a finer point on this: If WordPress wants to take the lead and *completely change* the de facto standard for how times have been reported to XML-RPC clients by all the major blogging systems, then it needs to do so with great thought and consideration for the impact this will have on clients, and for how it will put it apart from the other systems in terms of assumptions that can or can't be made about the times coming from it. Daniel From Joe.Cheng at microsoft.com Tue Jun 26 16:54:58 2007 From: Joe.Cheng at microsoft.com (Joe Cheng) Date: Tue, 26 Jun 2007 09:54:58 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> Message-ID: > My point? NONE of these systems uses an unadorned GMT-based time as > their default time representation. Is it a major bug? Yes, perhaps. This is why MetaWeblog just needs to die. For all its warts, Atom Publishing Protocol is at least a well-written specification that doesn't leave implementers guessing about basic, critical stuff like time zones. Either that or a quorum of the blog client and server implementers need to band together and create a profile that removes the ambiguity from MetaWeblog. I personally would be happy to contribute to that effort if others agree it is a good idea. The alternative is more no-win arguments like this one. Allan is correct in saying that using any kind of non-UTC timezone without any offset indicator is pretty broken (especially when the date provided when posting is interpreted as UTC). Daniel is correct in saying that existing clients will break if the behavior changes. Being a client implementer myself, I sympathize somewhat with Daniel, but at least Allan's approach leads to somewhere actually sane/stable in the long- term, even if there is some immediate pain. What all the servers are doing today makes NO sense (that's why Windows Live Writer doesn't bother to parse dates from getPost/getRecentPosts--there's nothing sensible we can do with those dates). From jalkut at red-sweater.com Tue Jun 26 17:04:20 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 13:04:20 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> Message-ID: <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> On Jun 26, 2007, at 12:54 PM, Joe Cheng wrote: > Either that or a quorum of the blog client and server implementers > need to band together and create a profile that removes the ambiguity > from MetaWeblog. I personally would be happy to contribute to that > effort if others agree it is a good idea. I think this is a good idea and I'm for anything that will fix the problem long-term, as long as clients are given a chance to accommodate it. It also seems like something that all of the server providers need to sign off on at once, or else it's not very useful. A compromise solution that would muddy the XML namespace but would at least allow for all parties to "win" would be to add a separate XML attribute for clients who want the GMT time explicitly. dateCreated20070623T01:22:18 wp_dateCreated20070623T06:22:18 This would enable WordPress to both lead by example and stay with the rest of the pack until they catch up. And the namespace expansion would be consistent with other WordPress extensions that are currently being added. (This might fall into that elusive "more ingenious solution" category I was alluding to) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jalkut at red-sweater.com Tue Jun 26 17:07:11 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 13:07:11 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> Message-ID: On Jun 26, 2007, at 1:04 PM, Daniel Jalkut wrote: > This would enable WordPress to both lead by example and stay with > the rest of the pack until they catch up. And the namespace > expansion would be consistent with other WordPress extensions that > are currently being added. Let me point out however that I do see and feel for the fact that this would require clients to update to achieve the level of "bug-fixed" status that Allan observed 2.2 to be. But I think it's appropriate for clients to change or radically changed behavior, and for clients to be able to stay the same for radically the same behavior. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joe.Cheng at microsoft.com Tue Jun 26 17:25:49 2007 From: Joe.Cheng at microsoft.com (Joe Cheng) Date: Tue, 26 Jun 2007 10:25:49 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> Message-ID: > A compromise solution that would muddy the XML namespace but would > at least allow for all parties to "win" would be to add a separate > XML attribute for clients who want the GMT time explicitly. Or how about a separate member that says what time zone is being used? This way there's no data duplication. dateCreated 20070623T01:22:18 dateCreatedTimeZone +08:00 From jalkut at red-sweater.com Tue Jun 26 17:31:12 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 13:31:12 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> Message-ID: On Jun 26, 2007, at 1:25 PM, Joe Cheng wrote: > Or how about a separate member that says what time zone is being > used? This way there's no data duplication. The only question that comes up is then you have to detect whether the "old-style" date is in fact one of these unusual beasts that has the time-zone tacked in. Maybe not a big deal, but you'd then have the question of whether the additional time-zone metadata is an affirmation of the built-in time zone, or a further adjustment to it. I think I prefer the separate field because it clearly delineates the meanings of the fields. One is "server-specific meaning", and one is GMT. Each is fully independent and parseable without regard to the other (if the client doesn't want to regard one or the other). > > dateCreated > > 20070623T01:22:18 > > > > dateCreatedTimeZone > +08:00 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joe.Cheng at microsoft.com Tue Jun 26 18:23:43 2007 From: Joe.Cheng at microsoft.com (Joe Cheng) Date: Tue, 26 Jun 2007 11:23:43 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> Message-ID: > The only question that comes up is then you have to detect > whether the "old-style" date is in fact one of these unusual > beasts that has the time-zone tacked in. Maybe not a big > deal, but you'd then have the question of whether the > additional time-zone metadata is an affirmation of the > built-in time zone, or a further adjustment to it. If the time is in UTC, then the dateCreatedTimeZone is Z, meaning no further offset is required. The rule would be, dateCreated with dateCreatedTimeZone applied = UTC. Period. dateCreated is problematic because there is no explicit time zone information. I'm simply suggesting we add explicit time zone information. > I think I prefer the separate field because it clearly > delineates the meanings of the fields. One is "server- > specific meaning", and one is GMT. Each is fully independent > and parseable without regard to the other (if the client > doesn't want to regard one or the other). That's exactly why it makes me uncomfortable: each is fully Independent yet they're supposed to represent the same underlying value. There's value in not repeating yourself-- you can eliminate even the possibility of self-contradiction. Anyway, we probably shouldn't spend too many calories on this until Joseph chimes in on what WordPress would be open to. From jalkut at red-sweater.com Tue Jun 26 18:29:41 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 14:29:41 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> Message-ID: <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> On Jun 26, 2007, at 2:23 PM, Joe Cheng wrote: > If the time is in UTC, then the dateCreatedTimeZone is Z, > meaning no further offset is required. The rule would be, > dateCreated with dateCreatedTimeZone applied = UTC. Period. Yeah - OK. If the contract is that you can always append the time zone value to the dateCreated value then I'm good with it. 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. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joe.Cheng at microsoft.com Tue Jun 26 18:58:00 2007 From: Joe.Cheng at microsoft.com (Joe Cheng) Date: Tue, 26 Jun 2007 11:58:00 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> Message-ID: > 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. From jalkut at red-sweater.com Tue Jun 26 19:04:27 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 15:04:27 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> Message-ID: 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, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at randomnetworks.com Tue Jun 26 19:35:03 2007 From: joseph at randomnetworks.com (Joseph Scott) Date: Tue, 26 Jun 2007 12:35:03 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> Message-ID: <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> 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/ From Joe.Cheng at microsoft.com Tue Jun 26 19:42:14 2007 From: Joe.Cheng at microsoft.com (Joe Cheng) Date: Tue, 26 Jun 2007 12:42:14 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> Message-ID: > 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. If we do include the Z, then it needs to not use the XML-RPC date/time datatype... which come to think of it, means people will have to parse the date themselves. I think that's a good reason NOT to include the Z. And come to think of it, adding a timezone field instead of a GMT field means people will have to parse a timezone, which no XML-RPC library will help you with. Daniel, I think you were right--we should just do dateCreatedUtc or whatever instead. From jalkut at red-sweater.com Tue Jun 26 19:44:25 2007 From: jalkut at red-sweater.com (Daniel Jalkut) Date: Tue, 26 Jun 2007 15:44:25 -0400 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> Message-ID: On Jun 26, 2007, at 3:35 PM, Joseph Scott wrote: > 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? Assuming I'm reading the diffs correctly, and understand your intention, this will put the source tree back to pre-2.2 behavior, right? That is, it will return to being a server-specific time (GMT adjusted for blog time-zone offset). I agree that doing this will put WP behavior back to something akin to what the vast majority of blogging systems do, right or wrong. It will incidentally also remove any bugs my users had specifically with WP 2.2. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at randomnetworks.com Tue Jun 26 20:26:21 2007 From: joseph at randomnetworks.com (Joseph Scott) Date: Tue, 26 Jun 2007 13:26:21 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> Message-ID: <65D7E507-1518-4667-9166-227D62DE4D3E@randomnetworks.com> On Jun 26, 2007, at 12:42 PM, Joe Cheng wrote: >> 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. > > If we do include the Z, then it needs to not use the XML-RPC date/time > datatype... which come to think of it, means people will have to parse > the date themselves. I think that's a good reason NOT to include the > Z. Why can't we use the dateTime data type? I've read over the XML-RPC spec at http://www.xmlrpc.com/spec which I read to indicate that the dateTime format is to follow the ISO 8601 format. The other applicable section of the XML-RPC spec is: ---------- 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. ---------- Now I suppose this could be read as telling people that they can't include time zone data in a dateTime field. I read it as the server and the client should have negotiated that out in the documentation for the API being used. And if our documentation states that the new date_post_gmt field will always be the GMT of the post and always have the format of yyyyMMddThh:mm:ssZ then we still meet the XML-RPC spec. Nothing says that dateTime must never include time zone data. And if it did then it wouldn't be ISO 8601 then. That was my logic at any rate, I'm happy to hear thoughts from others on this. > And come to think of it, adding a timezone field instead of a GMT > field > means people will have to parse a timezone, which no XML-RPC library > will help you with. Daniel, I think you were right--we should just do > dateCreatedUtc or whatever instead. Cool, +1 for a new field with the complete GMT of the post date. -- Joseph Scott http://joseph.randomnetworks.com/ From joseph at randomnetworks.com Tue Jun 26 20:28:57 2007 From: joseph at randomnetworks.com (Joseph Scott) Date: Tue, 26 Jun 2007 13:28:57 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> Message-ID: On Jun 26, 2007, at 12:44 PM, Daniel Jalkut wrote: > On Jun 26, 2007, at 3:35 PM, Joseph Scott wrote: > >> 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? > > Assuming I'm reading the diffs correctly, and understand your > intention, this will put the source tree back to pre-2.2 behavior, > right? > > That is, it will return to being a server-specific time (GMT > adjusted for blog time-zone offset). I've not confirmed the exact behavior of each previous release, but yes I believe it will. > I agree that doing this will put WP behavior back to something akin > to what the vast majority of blogging systems do, right or wrong. > It will incidentally also remove any bugs my users had specifically > with WP 2.2. 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. -- Joseph Scott http://joseph.randomnetworks.com/ From Joe.Cheng at microsoft.com Tue Jun 26 20:42:43 2007 From: Joe.Cheng at microsoft.com (Joe Cheng) Date: Tue, 26 Jun 2007 13:42:43 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <65D7E507-1518-4667-9166-227D62DE4D3E@randomnetworks.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> <65D7E507-1518-4667-9166-227D62DE4D3E@randomnetworks.com> Message-ID: > Why can't we use the dateTime data type? I've read over the XML-RPC > spec at http://www.xmlrpc.com/spec which I read to indicate that the > dateTime format is to follow the ISO 8601 format. Because several popular XML-RPC parsing libraries will choke on the Z-- exactly the problem that started this thread, IIRC. Windows Live Writer originally formatted the dates with Z but we had to back away after one blog service after another choked on the dates. Anything written in .NET (they all use Cook Computing's XMLRPC.NET library) and a bunch of servers written in PHP would throw errors when encountering the Z. Don't bother looking for justification in the XML-RPC spec. It's useless. Note that it doesn't say to follow the ISO 8601 format. It just happens That the name of the tag is "dateTime.iso8601"--that's it. Now, it's understandable that you would interpret that to mean "any ISO 8601 conformant value is allowed", but it's also understandable that many XML-RPC library authors looked at the example and decided that the only format that is valid is yyyyMMddTHH:mm:ss, full stop. (Incidentally, we should be glad we don't have to parse ISO 8601--it's an unbelievably complex standard that lets you express dates in a bewildering array of different formats (including, for example, year and number of days into the year). Far, far too general for a simple machine-to-machine protocol like XML-RPC.) > That was my logic at any rate, I'm happy to hear thoughts from others > on this. Honestly, forget logic. XML-RPC and MetaWeblog are so vague/ambiguous, it's useless to argue about what the spec meant or intended. The only thing worth grabbing onto is what the de facto interpretation is. That's why I think it's important for us to document those de facto interpretations, and where there is none or where the status quo is Fundamentally flawed (as in time zone support), try and fix it. From Joe.Cheng at microsoft.com Tue Jun 26 20:52:58 2007 From: Joe.Cheng at microsoft.com (Joe Cheng) Date: Tue, 26 Jun 2007 13:52:58 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> <65D7E507-1518-4667-9166-227D62DE4D3E@randomnetworks.com> Message-ID: > Because several popular XML-RPC parsing libraries will choke on the Z Sorry, I realized I should explain exactly what I mean by this. Many/most XML-RPC libraries will save you the trouble of parsing the textual values that appear in XML-RPC requests/responses--instead they will use the inlined type tags to convert the text into natively typed values. So even if we add a never-before-used date/time field to MetaWeblog, just the fact that it's a date/time field means the XML-RPC library will attempt to parse it for you and probably fail (often loudly) if the format is not what it was expecting. From joseph at randomnetworks.com Tue Jun 26 21:58:02 2007 From: joseph at randomnetworks.com (Joseph Scott) Date: Tue, 26 Jun 2007 14:58:02 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> <65D7E507-1518-4667-9166-227D62DE4D3E@randomnetworks.com> Message-ID: On Jun 26, 2007, at 1:42 PM, Joe Cheng wrote: >> Why can't we use the dateTime data type? I've read over the XML-RPC >> spec at http://www.xmlrpc.com/spec which I read to indicate that the >> dateTime format is to follow the ISO 8601 format. > > Because several popular XML-RPC parsing libraries will choke on the > Z-- > exactly the problem that started this thread, IIRC. Windows Live > Writer > originally formatted the dates with Z but we had to back away after > one blog service after another choked on the dates. Anything > written in > .NET (they all use Cook Computing's XMLRPC.NET library) and a bunch of > servers written in PHP would throw errors when encountering the Z. > > Don't bother looking for justification in the XML-RPC spec. It's > useless. > Note that it doesn't say to follow the ISO 8601 format. It just > happens > That the name of the tag is "dateTime.iso8601"--that's it. Now, it's > understandable that you would interpret that to mean "any ISO 8601 > conformant value is allowed", but it's also understandable that many > XML-RPC library authors looked at the example and decided that the > only format that is valid is yyyyMMddTHH:mm:ss, full stop. I'm sorry, I thought you suggested another type because it didn't conform to the spec. Still stinks that so many parsers would have problems with even the most basic of time zone data. > (Incidentally, we should be glad we don't have to parse ISO 8601--it's > an unbelievably complex standard that lets you express dates in a > bewildering array of different formats (including, for example, year > and number of days into the year). Far, far too general for a simple > machine-to-machine protocol like XML-RPC.) Amen. At one point I downloaded a PDF of the spec (trying to remember the number pages, something like 40 plus). Yikes. >> That was my logic at any rate, I'm happy to hear thoughts from others >> on this. > > Honestly, forget logic. XML-RPC and MetaWeblog are so vague/ambiguous, > it's useless to argue about what the spec meant or intended. The only > thing worth grabbing onto is what the de facto interpretation is. > That's why I think it's important for us to document those de facto > interpretations, and where there is none or where the status quo is > Fundamentally flawed (as in time zone support), try and fix it. Well, good to know I'm not the only one who finds some of this stuff fuzzy. I totally agree with your conclusion, these de facto standards need to be spelled out and documented and then improved where possible. -- Joseph Scott http://joseph.randomnetworks.com/ From m123ixd02 at sneakemail.com Wed Jun 27 03:11:50 2007 From: m123ixd02 at sneakemail.com (Allan Odgaard) Date: Wed, 27 Jun 2007 05:11:50 +0200 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> Message-ID: <31559-42762@sneakemail.com> 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 ``), 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 `` 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 `` type, i.e. difficult to handle with existing XML-RPC parsers. 2. Provide the offset (in minutes) as an additional `` 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 ``) 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). From joseph at randomnetworks.com Thu Jun 28 15:55:42 2007 From: joseph at randomnetworks.com (Joseph Scott) Date: Thu, 28 Jun 2007 08:55:42 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <31559-42762@sneakemail.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> <31559-42762@sneakemail.com> Message-ID: <7413BB1C-8F56-4C1B-A051-6CF4D0AB5249@randomnetworks.com> On Jun 26, 2007, at 8:11 PM, Allan Odgaard wrote: Allan, thank you for the detailed outline, I've trimmed it for brevity. > 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 > ``) 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). I'm still a bit torn on what exactly the new field should contain. Allan's arguments for the new field to be an offset is attractive. No data is duplicated and it does a provide a way to determine the GMT date. My concern with the offset approach is that if we are dealing with libraries that are unable to deal with time zone data, it seems likely that they'll also have problems manipulating dates using the offset to get the GMT. I'm not 100% sold either direction yet. -- Joseph Scott http://joseph.randomnetworks.com/ From Joe.Cheng at microsoft.com Fri Jun 29 18:11:38 2007 From: Joe.Cheng at microsoft.com (Joe Cheng) Date: Fri, 29 Jun 2007 11:11:38 -0700 Subject: [wp-xmlrpc] WP 2.2.1 breaks Ruby 1.8.2 In-Reply-To: <7413BB1C-8F56-4C1B-A051-6CF4D0AB5249@randomnetworks.com> References: <17596-17653@sneakemail.com> <10622-65514@sneakemail.com> <9534-28958@sneakemail.com> <2919E114-D199-48C1-9DCB-26CC0C4E2D83@red-sweater.com> <275F4156-57B0-4587-871C-4FF33F284CC3@red-sweater.com> <4F1664EC-6E5C-4E77-A7F7-737E161EE042@red-sweater.com> <8145D45B-0F3E-468B-86B0-8B303E7B70E4@randomnetworks.com> <31559-42762@sneakemail.com>, <7413BB1C-8F56-4C1B-A051-6CF4D0AB5249@randomnetworks.com> Message-ID: > I'm still a bit torn on what exactly the new field should contain. > Allan's arguments for the new field to be an offset is attractive. > No data is duplicated and it does a provide a way to determine the > GMT date. I agree--the offset is more elegant, but just using the UTC date is likely more practical. I think the ship has long since sailed on making MetaWeblog being elegant, so I'd personally lean toward practical :) If we do the UTC date then no parsing at all will be required, given a reasonable XML-RPC library. That seems like a real benefit to me.