[wp-xmlrpc] Daylight saving time and edting past post

[Joseph Scott]

On Mar 1, 2008, at 8:34 PM, Toby Simmons wrote:

> I'm the lead developer for Zempt, a (slow developing) desktop blogging
> client and I've got a question. I tried to explain the problem in a
> blog
> post -
> http://www.simmonsconsulting.com/wordpress/2008/02/29/daylight-
> saving-time-a
> nd-wordpress-xmlrpc/ - but I'll summarize it here.


Is this the same Zempt that Adam Kalsey and Bill Zeller started?  Are
you working from code they left on Source Forge?


> The problem occurs when you edit a previous post that was written in a
> different daylight saving state than what is currently in effect.
> Say it's
> NOT daylight time right now but I edit a post that was posted during
> daylight time. When this post is prepared for re-posting, Zempt
> will convert
> the post's date and time to UTC (which, for me in the Central time
> zone is
> -0500 during daylight time) then post it with xmlrpc. The problem
> is that
> currently my blog is set for standard time, which for me is -0600,
> so when
> WordPress processes the post, it bumps up the post date an hour
> earlier. If
> I edit this post several times, each time it is republished, the
> post date
> is bumped an hour earlier each time.
>
> The same thing occurs if it is daylight time and you edit a post
> that was
> written in standard time, except it gets later and later each time
> it is
> posted.


Getting the date/time right has easily been the trickiest problem
with the XML-RPC APIs since I started working with them.  This
specific problem is new to me, but there are other blog client
authors on the list who have probably seen this.  If they have a
technique for dealing with this perhaps they'll suggest something.


> Is there a way to fix this or to tell WordPress what time zone
> offset to use
> for a particular post with xmlrpc?


There currently is no API for determining the current time zone
offset for a WordPress blog.  That said there are a few things that
might help you out here.  For metaWeblog.getPost we added a new field
called 'date_created_gmt'.  This field by definition is ALWAYS the
gmt date/time of a post, even if there is no trailing Z or time zone
offset.  This field is also accepted now by metaWeblog.newPost and
metaWeblog.editPost and if it is present will be used instead of
'dateCreated' field.  This will provides more precise date/time
handling.

I'm hesitant to even mention this, but I suppose to could do the math
and figure out the different between 'dateCreated' and
'date_created_gmt' and figure out what the offset is.  This of course
screams ugly hack :-)

We've discussed adding a wp.getBlogOptions( ) method that would
expose a variety of settings/options for a WordPress blog, including
the time zone offset.  I haven't done any real work on that yet.
Hopefully once 2.5 ships (later this month) I'll be able to get that
in for inclusion to 2.6.


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