One commit authored in the future could throw off everything

[hahn-kev]

Right now if a computer were to have it's clock set for 2030, and it made commits and synced them, then with our hybrid logical clock we would always use that as the start date which would throw off the dates basically forever (or till 2030 in this example).

It's probably safe to say that the server will never get far out of sync, so we could just have the server reject commits from the future, 5 min in the future further more and it gets rejected?

However if we did that then a user would need some way to correct the dates on their commits so they could get back in sync. I'm not sure the best way to do that, and it could get complicated if you mix in offline sync, because those commits could have been sent somewhere else.

[softlion]

When pushing changes to the server, let the server return the fixed dates, and update the local items with those dates.
Thus you'll get only server dates on the client in the end after all local changes have been synced.