On Tue, 2012-03-13 at 12:57 +0100, Thomas Pequet wrote: > Le 13/03/2012 10:43, Patrick Ohly a écrit : > > On Tue, 2012-03-06 at 17:16 +0100, Thomas Pequet wrote: > > > Le 06/03/2012 13:14, Patrick Ohly a écrit : > > > > Thomas Pequet wrote: > > > > It's a bit curious that in one case the anchor is a time stamp, in the > > > > other a number. Both are strings sent by the Memotoo server. Did you > > > > perhaps change the anchor formatting from "seconds since epoch as time > > > > stamp" to "seconds since epoch as integer"? I haven't checked whether > > > > 20120228T115051Z matches 1330608696000 when interpreted like that. > > > It is strange, Memotoo return only date with seconds (ex: > > > 1330608696000) not timestamp... So why SyncEvolution store the > > > timestamp ???? > > SyncEvolution and libsynthesis treats the sync anchor as string. It > > should never convert to a time stamp. Does your user still have other > > logs? He can do a "grep -l -r 20120228T115051Z ~/.cache/syncevolution" > > to find all relevant log files.
I got logs for two sessions from Thomas. In the session from 2012-02-28 there is an entry for the anchor from Memotoo as UTC date/time: [2012-02-28 12:50:51.753] Received <next> Remote Server Anchor='20120228T115051Z' (to be compared with <last> in NEXT session) Then in the next session, Memotoo reverts to the integer format: [2012-03-01 14:31:36.449] Saved Last Remote Server Anchor='20120228T115051Z', received <last> Remote Server Anchor='1330603400000' (must match for normal sync) [2012-03-01 14:31:36.449] Received <next> Remote Server Anchor='1330608696000' (to be compared with <last> in NEXT session) This confirms my theory that the Memotoo server switched between different ways of formatting its internal time stamp. There are no XML message dumps to proof it, but I am nevertheless confident that this really what the Memotoo server sent. There simply isn't any code in libsynthesis which transforms remote server anchors. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
