XMLRPC / TextMate / Date-Header

[pilif]

Hi again,

I had a couple of free minutes at work, so I had a look at the dateCreated-problem when posting to s9y via TextMate.

Guess what: It was a bug in MovableType that caused the whole mess and I fixed it with yet another patch to the Blogging-Bundle (the details are on the mailing list archive, but the patch is here).

But this time around, I think some work is needed in s9y too:

First, it should not set the timestamp to 0 when XML_RPC_iso8601_decode() can't decode the submitted timestamp.

One thing is to just ignore the header when XML_RPC_iso8601_decode() returns 0. This makes it impossible to set the creation date to 1970 though, so the best fix would be to fix XML_RPC_iso8601_decode() to distinguish between the valid 1970 timestamp and an invalid one:

Code: Select all

--- RPC.php     2007-03-23 17:05:31.772271147 +0100
+++ RPC_patched.php     2007-03-23 18:42:03.807130973 +0100
@@ -1829,7 +1829,7 @@
  */
 function XML_RPC_iso8601_decode($idate, $utc = 0)
 {
-    $t = 0;
+    $t = -1;
     if (ereg('([0-9]{4})([0-9]{2})([0-9]{2})T([0-9]{2}):([0-9]{2}):([0-9]{2})', $idate, $regs)) {
         if ($utc) {
             $t = gmmktime($regs[4], $regs[5], $regs[6], $regs[2], $regs[3], $regs[1]);

and then ignore the passed timestamp if we get -1 back from XML_RPC_iso8601_decode()

This has the drawback of having to wait for yet another third party to merge a patch before stuff begins working.

The other problem is that the dateCreated sets the entries creation date.

I know that this sounds kind of logical, but the problem is that the creation date isn't at all obvious within s9y. As far as I can see (using a default installation without any additional plugins but the XML-RPC one) there's no way to see (aside of the sort order) and let alone change that value via the administration interface.

I would recommend to change s9y to actually modify the change date of the entry instead of the creation date. Or we set last_modified to the current timestamp but then we must provide another user interface element to actually see and change the creation time. As it stands now, the RPC-interface provides access to more functionality than the web interface does.

If I get answers to the following questions, I will do the patching needed on sunday afternoon:

• How do you want to have invalid timestamps handled? Do you want to ignore them if XML_RPC_iso8601_decode() returns 0? Or do you want me to patch the local copy of XML_RPC_iso8601_decode() and then ignore the return value of -1? In that case, I will submit that patch back to PEAR, so it'll maybe get merged to upstream sometime. IMHO, it's wrong to return 0 on failure as 0 is a valid (though unlikely) timestamp.
• How do you want to have the creation date issue handled? Should dateCreated just det the last_modified date of the entry? Or should I set last_modified to time() and update the UI to provide a field to set the actual creation time stamp?

I'm looking forward to your answers!

Philip

[garvinhicking]

Hi!

First off, thanks for your work on this. Sadly I'm not feeling so well, so I might not have gottne the full intent of your posting.

I would recommend to change s9y to actually modify the change date of the entry instead of the creation date. Or we set last_modified to the current timestamp but then we must provide another user interface element to actually see and change the creation time. As it stands now, the RPC-interface provides access to more functionality than the web interface does.

Usually, what you enter into the "Date" Box when you edit an entry frmo the s9y interface, that date is applied to both "last_modified" and "timestamp" fields. Usually last_modified gets pushed to the date of when you save an entry, and 'timestamp' gets filled depending on the date you entered into the input box?

[*] How do you want to have invalid timestamps handled? Do you want to ignore them if XML_RPC_iso8601_decode() returns 0? Or do you want me to patch the local copy of XML_RPC_iso8601_decode() and then ignore the return value of -1? In that case, I will submit that patch back to PEAR, so it'll maybe get merged to upstream sometime. IMHO, it's wrong to return 0 on failure as 0 is a valid (though unlikely) timestamp.

IMHO we should discard the border case of a 0 return stamp, and detect "0" as "invalid". Patching the 3rd party file IMHO raises harder maintainability, and when somebody wants to use "0" as a timestamp, he might as well add one second to that posting to make the entry valid? IMHO the benefits are clearly on the upside of things.

[*] How do you want to have the creation date issue handled? Should dateCreated just det the last_modified date of the entry? Or should I set last_modified to time() and update the UI to provide a field to set the actual creation time stamp?

How about setting the dateCreated field to "timestamp", and applying the current timestamp ("NOW") to last_modified?

HTH,
Garvin