A robust implementation of this is planned for the future. In general syncing is a difficult problem if there is a potential for conflicts. However, there are two simple ways to work around the problem:
Only use timebook on one machine, and access that machine over ssh when you need to start a timesheet remotely.
If you want to keep X and Y in sync, before altering the state of a timebook on Y, push changes from X to Y, and vice versa.
Neither way is ideal (I personally use #1 for now), but it will eventually be fixed.
I was thinking about this today as I left for work shortly after installing timebook. Here's the interface that makes sense to me:
throw -- mark an entry end time as occurring on a remote host, saves current time as a hint
catch -- mark an entry start time as occurring on a remote host, saves current time as a hint
merge -- given an sqlite DB from the remote host (which you get with scp or whatever), join matching throw/catch pairs and import any entries that don't already exist in the local DB.
throw/catch entries match if
they are in the same time sheet
the catch time hint is after the throw time hint
This could fail if you throw entry-x from host A, catch it on B, start entry-y on B, throw entry-y, and catch on C. Then you merge C into A which will join the x-throw with the y-catch. Fix by merging B, which will note that the x-catch/y-throw occurs during the x-in/y-out entry and split that entry in to the proper x-followed-by-y configuration.
I haven't implemented any of this yet, but if it sounds like a viable plan I'll give it a shot.