XML-RPC metaWeblog.getPost and metaWeblog.getRecentPosts don't return posts' modification date.

[ocollet]

If a post has been modified, there's currently no way to get the date it happened. When retrieving a single or several posts via XML-RPC, the only date returned is the creation date.

This would help to have the modification date, especially in the case of data synchronization.

Added the post modification date to metaWeblog.getRecentPosts and metaWeblog.getPost

I like this change, with one exception. The only new field that we should expose is 'date_modified_gmt'. Time zone issues were a major source of confusion for many clients, which is why I added the GMT data fields. I think exposing more non-GMT data at this point will only increase that confusion.

I uploaded a modified version of your diff : http://core.trac.wordpress.org/attachment/ticket/19027/xmlrpc.diff - with just the 'date_modified_gmt' field.

I'd be fine with committing this modified diff.

Replying to josephscott:

I like this change, with one exception. The only new field that we should expose is 'date_modified_gmt'. Time zone issues were a major source of confusion for many clients, which is why I added the GMT data fields. I think exposing more non-GMT data at this point will only increase that confusion.

Since these date_modified fields are read-only, I'm not as concerned with exposing both GMT and non-GMT versions. If you only expose the GMT version, then XML-RPC clients have to do their own datetime math (and call getOption to figure out the blog display timezone) to determine what the displayed value should be.

Replying to maxcutler:

If you only expose the GMT version, then XML-RPC clients have to do their own datetime math (and call getOption to figure out the blog display timezone) to determine what the displayed value should be.

I agree. We should expose both the GMT and local post modified fields ... but we should be consistent in how we name them. If we're using post_modified_gmt we should also use post_modified rather than postModified.

I was actually trying to get consistent with the postCreated property, therefore my suggestion to have the following fields:
postCreated, postModified, post_date_gmt and post_modified_gmt.

Replying to ericmann:

Replying to maxcutler:

If you only expose the GMT version, then XML-RPC clients have to do their own datetime math (and call getOption to figure out the blog display timezone) to determine what the displayed value should be.

I agree. We should expose both the GMT and local post modified fields ... but we should be consistent in how we name them. If we're using post_modified_gmt we should also use post_modified rather than postModified.

After further discussion I agree that exposing the non-GMT modified date won't hurt anything. My primary recommendation to clients is still to use the GMT field.

I've uploaded xmlrpc.2.diff which is basically the original patch with a few minor changes. The fields are date_modified and date_modified_gmt since there are no existing camelcase field names that we need to worry about in terms of backwards compatibility.

This patch looks good - I think we should always expose both our internal GMT representation of a date and the timezone adjusted date because they won't necessarily be based on the current Timezone config of the blog - timezone changes, DST, etc.

In [19883]:

Expose the post modified date (in blog TZ and GMT) via XML-RPC

Props ocollet
Fixes #19027

Probably has the same bug as #19733 looking at the diff.