So, it’s been a while since I’ve had a moment to post. On Thursday night I stayed up late and got our new blog software working. Even though OS X Server comes with a version of Blojsom I decided to use WordPress. Silly me. I decided that since WordPress 2.0 is in Beta, I would use the Beta version. Well, that wasn’t the brightest of ideas. It was easy to install.
Let me take a moment and say that while I’ve used various Linux distributions for years, I’ll be hard pressed to migrate off OS X. To enable Apache is as simple as using Apple’s Server Admin tool. Nice, easy to use, intuitive GUI. Even though I know the file formats and could manually edit the files, it was far faster than doing it in vi or emacs. Same with MySQL — nice little program to run to enable MySQL at system boot time and it lets you set the privileged user name and password. So, yes, I am lazy. I could have done the same thing in a Linux distribution without a problem but the richness of the UI made doing in in OS X, well, idiot proof.
So, back to WordPress 2.0 Beta 2. It, itself, was easy to install and configure. Rather than do the “mu” version, I went with running three simultaneous instances (figuring I wouldn’t really notice the wasted resources). Moved the content into a separate directory for all of them via sym links (to make going to version 2.0 easier).
Well, it all worked… Until… I tried using Ecto (our preferred blog client). Then strange things started happing. The posts were in seriously wrong timezones. Figuring it was an Ecto issue I played with configs for a long time on the Ecto side. Finally I decided to look in the MySQL database itself. WordPress maintains two database columns for time — “local time” and “GMT” time for each post. We’re in the Eastern timezone. The “GMT” entry in the WordPress database was 10 hours ahead of Eastern and the “Local” time was spot on. Strange. Turns out in the xmlrpc.php file, WordPress (IMHO) has poor logic — they look at the date sent by the blog client (like Ecto). They assume the date is in GMT unless the client includes a timezone. Fair enough. (In Ecto’s case it does not include a timezone). They figure out the “local time” (post_date) correctly. They then call a helper function to convert the time given by the client (Ecto) to GMT. That helper function assumes that the lack of timezone means it’s local time. Oops!
So, WordPress has the same code path making two different assumptions: First it assumes that a given input lacking timezone is “local time” then it assumes that the given input lacking timezone is “GMT”.
Anyway, the new site/themes are active and all seems well.