On 26. Feb 2007, at 04:42, Steven W. Riggins wrote:
First, for the archive, let me just point to <http://macromates.com/ wiki/Bundles/HowToContribute> (to answer your original question)
[...] When I'd post, it would lose the time, etc.
This is probably not related, but I disabled sending the date to WordPress systems (unless a variable is set) [1].
It seems I may have made a mistake though. We convert the date to UTC because no TZ information is sent to the server [2].
The spec has the following note about TZ:
> What timezone should be assumed for the > dateTime.iso8601 type? UTC? localtime?
> Don't assume a timezone. It should be > specified by the server in its > documentation what assumptions it makes > about timezones.
So in this case, we should find what TZ to use in the MetaWeblog API [3]. Of course they don’t say anything about it.
So next step, look at an actual implementation: Here I revisited WordPress, and it turns out, that if it receives a date w/o TZ info [4], and some variable is not GMT (I didn’t pursue that) it will expect the date to be in the TZ which is configured under TZ in the admin UI.
So maybe we actually should send the date to WordPress, and send it in the users local time zone, and assume the user will make the time zone in his admin UI match that of his local system (from where he blogs)?
Personally though, I think this is rather fragile -- i.e. we require the user to setup something, which strictly is not necessary, and should the user move between different time zones, he needs to keep the web interface updated.
OTOH if this is really how things were designed, we probably complicate things by not following “the standard” -- although setting the time zone offset to zero in the WordPress admin, would be effective, with our current implementation.
Brad: I take it that moving to the Atom Publishing Protocol will free us of these concerns? Presently I am a little torn on whether we should leave things as-is, or if we should go back to send the date in the users TZ, and expect users to do the appropriate server-side configuration, although I have no idea about the ability to do this in systems other than WordPress.
[1]: I deemed it not possible to construct a workaround, after having looked at the WordPress source.
[2]: The example given for <dateTime.iso8601> in the XML-RPC spec (http://www.xmlrpc.com/spec) does not contain any information about time zone. It is tempting to think the field is ISO 8601 (so we could add it), but the few implementations of XML-RPC receiving code I have looked at, does not expect that.
[3]: http://www.xmlrpc.com/metaWeblogApi
[4]: In the WordPress case, it does not expect dates in other formats than YYYYMMDDTHH:MM:SS, but it does allow for a trailing time zone.