Yeah, see I don't really know how other people are using the protocol, but I guess it could be implemented in a backward compatible way just by adding a "createtime" param in addition to the "time" param. This would make the response more bulky, but would still allow clients to display the update time, since I suppose they could be using the call's time param that way. Also, pretty much every client application that relies on syncitems saves the most recent time param returned by syncitems and uses it in their next syncitems call, so the update time is definitely necessary to the protocol just to keep that working.
As I've meditated on this in my past few days of minimal internet connectivity, I've become unconvinced that the syncitems call is the best place for the log time, though, because syncitems is specifically for figuring out what things are different since the last time syncitems was called, and the create time of an entry doesn't really figure into that functionality. Adding the log time to the response there doesn't make sense to me, but maybe I don't have good instincts -- I naturally expected it to be in the getevents response, where it definitely is not.
A slightly-related curiosity: LJ's response currently includes a (not documented?) param that DW's does not seem to, timestamp, and I thought that might be what I was looking for (if I were migrating things from LJ, which I am not), but then it turned out that is just a timestamp-style version of the eventtime param, so not useful in any way, which would explain why DW cut it from the protocol.
Morning Rambling
As I've meditated on this in my past few days of minimal internet connectivity, I've become unconvinced that the syncitems call is the best place for the log time, though, because syncitems is specifically for figuring out what things are different since the last time syncitems was called, and the create time of an entry doesn't really figure into that functionality. Adding the log time to the response there doesn't make sense to me, but maybe I don't have good instincts -- I naturally expected it to be in the getevents response, where it definitely is not.
A slightly-related curiosity: LJ's response currently includes a (not documented?) param that DW's does not seem to, timestamp, and I thought that might be what I was looking for (if I were migrating things from LJ, which I am not), but then it turned out that is just a timestamp-style version of the eventtime param, so not useful in any way, which would explain why DW cut it from the protocol.