Daylight saving time and WordPress XMLRPC
Zempt is a desktop blogging client and writing tool that is especially useful for those that have multiple blogs. It enables you to write, edit and spell check new blog posts as well as edit previous blog entries by downloading, editing and reposting them. Having been involved with the Zempt project for five years (and being the only developer for the last two or three) I am pretty familiar with some of the issues that can come up with remote editing of blog posts.
One of the most puzzling issues has been how to handle daylight saving time offsets with WordPress. Every time I think I have the issue solved, I discover that I’ve broken something else. This might be an issue particular to WP and how it handles timezone offsets.
Using Zempt to create brand new posts using the default date (which is “right now, whenever you post it”) works fine, every time. And editing previous posts from your blog that were written during the current daylight saving time state also works fine. In other words, if right now it is daylight saving time and the post you are editing was written during daylight saving time, that post’s time will stay the same. By the same token, If it is currently standard time and the post you are editing was written during standard time, again, the post’s time stamp will remain unaffected.
The problem comes when editing a post that was written in a different daylight savings state. Stay with me here.
Let’s suppose you keep your WordPress blog settings up to date … when daylight saving time kicks in, you update your blog’s timezone offset promptly. Same thing when daylight time ends, you change your blog’s timezone offset the same day. Take my blog for example. I am in the Central timezone, so my timezone offsets are -0500 during daylight time and -0600 during standard time.
Now let’s say it is currently NOT daylight saving time (-0600 for me) and my blog settings are up to date and I want to edit a post that was written while daylight time was in effect. The post I am editing has a time stamp of 9:00 am on Oct. 31, 2007 (CDT).
When I download that post and edit it with Zempt, it knows that Oct. 31 was during daylight time. When I save that post back to my blog, Zempt will dutifully convert that time stamp to University Time Coordinate (UTC) based on the post’s date, which means in this example, it will add five hours, which is 2:00 pm on Oct. 31, 2007 (UTC).
Unfortunately, WordPress thinks that any post it receives (regardless of the date) must be -0600 hours off from UTC because that’s what its timezone offset is, so it makes the post’s time 8:00 am on Oct. 31, 2007 (which is UTC minus six hours) so my original post shows that it is an hour earlier than it really was.
If I edit this post again with Zempt, the same thing happens, which means it becomes 7:00 am on Oct. 31, 2007. If you do this enough times, the time stamp gets really screwed up.
A similar problem occurs if you edit a post during daylight time that has an original post date that was standard time, except the post gets pushed forward an hour each time you save it to your blog.
I’ve tested Ecto (on Windows) and it has the same problem.
So here is my question: What should an offline blog writing tool like Zempt do to accommodate this problem? One thing I’ve considered is to have Zempt check the local machine’s current daylight setting vs. the post’s date and either add or subtract the appropriate amount from the post date’s UTC to have it work out but this seems to be a poor workaround. What would be nice is if there was a way through XMLRPC to tell WordPress to use a specified timezone offset for a particular post.
Just ran across a similar issue. My approach was to work around the issue using date_created_gmt to always get an unambiguous timestamp. This way I’m at least consistent across getPost/editPost calls, and (at least in theory) you could wrap this using the user’s locale to present actual timestamps (although I’m too lazy for right now).
Ethan