I'd be fine with you sending the whole bundle and I can diff it myself. Can you summarize the changes in terms of their functionality?

On Feb 25, 2007, at 7:14 PM, Steven W. Riggins wrote:

In early Jan I made a bunch of changes to my blogging bundle, some overrides, some I had to edit the .rb files by hand.

Whats the best way to compare my changes to the svn tree and submit them as a patch to be reviewed?

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

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.

On Feb 26, 2007, at 12:18 AM, Steven W. Riggins wrote:

I'd make a post, and I am in -8, server in -5, and then I would edit it, repost and get TWO posts on my server, with one being well in the past, due to totally wrong time.

Its late. What I meant to write (and wow what a brain fart) is that I would post, edit, post and not see my post on my blog, because it was so far in the past, so I'd post again.