ecto for Windows: The dateTime problem in TypePad and its relative only (exclusive Movable Type)
I'm sorry for you to my broken English.
I found the dateTime problem in TypePad and its relative only (exclusive Movable Type), generated when an entry is posted by 'ecto for Windows'.
This problem is:
- a problem by the side of a server, but not a problem by the side of a client.
- caused by TypePad and its relative only (exclusive Movable Type)
- timestamp of an entry specified in local time, but a server is handling with this timestamp as specified GMT (Greenwich Mean Time). Then, after posting, this entry's timestamp is wrong as local time.
- an entry taken after posting has timestamp as local time, but the format of this timestamp stands for GMT. ('yyyy-mm-ddThh:mm:ssZ', 'Z' stands for GMT formatting timestamp. In fact, this dateTime string must be formatted in ''yyyy-mm-ddThh:mm:ss' [without 'Z'] !!)
This problem will be resolved:
- In posting entry, blogger API client gives empty dateTime field.
- In reposting entry after edited or modified, blogger API client also gives empty dateTime field.
Recieved an empty dateTime field, blogger API server will give current local time, or last posted time. It's work right in almost blog tools. I already tested this process with my tiny blogger client, for TypePad, Movable Type, and so on.
Thanks for your reading.
投稿者: tsupo 2004.05.28 午前 11:44 | 固定リンク | | | | |
The problem of the post time is due to the ambigous wording in the XML-RPC specification. You can read more in details in this post: http://groups.yahoo.com/group/XMLRPCNET/message/187
Sending an empty time string to the server will only solve the problem with post that is immediate. If the user wants to set the post time to some time later or earlier, the application will still have to send the custom time to the server.
ecto handles time specialy for TypePad and cocolog services right now but may be it is still not working properly. I will investisgate more this weekend.