cocoa - What are common pitfalls of timestamp based syncing? -

i implementing first syncing code. in case have 2 types of ios clients per user sync records server using lastsynctimestamp, 64 bit integer representing unix epoch in milliseconds of last sync. records can created on server or clients @ time , records exchanged json on http.

i not worried conflicts there few updates , same user. however, wondering if there common things need aware of can go wrong timestamp based approach such syncing during daylight savings time, syncs conflicting another, or other gotchas.

i know git , other version control system eschew syncing timestamps content based negotiation syncing approach. imagine such approach apps too, using uuid or hash of objects, both peers announce objects own, , exchange them until both peers have same sets.

if knows advantages or disadvantages of content-based syncing versus timestamp-based syncing in general helpful well.

edit - here of advantages/disadvantages have come timestamp , content based syncing. please challenge/correct.

note - defining content-based syncing simple negotiation of 2 sets of objects such how 2 kids exchange cards if gave them each parts of jumbled pile of 2 identical sets of baseball cards , told them through them announce , hand on duplicates found other until both have identical sets.

• johnny - "i got card."
• davey - "i got bunch of cards. give me card."
• johnny - "here card. gimme bunch of cards."
• davey - "here bunch of cards."
• ....
• both - "we done"

advantages of timestamp-based syncing

• easy implement
• single property used syncing.

disadvantages of timestamp-based syncing

• time relative concept observer , different machine's clocks can out of sync. there couple ways solve this. generate timestamp on single machine, doesn't scale , represents single point of failure. or use logical clocks such vector clocks. average developer building own system, vector clocks might complex implement.
• timestamp based syncing works client master syncing doesn't work peer peer syncing or syncing can occur 2 masters.
• single point of failure, whatever generates timestamp.
• time not related content of being synced.

advantages of content-based syncing

• no per peer timestamp needs maintained. 2 peers can start sync session , start syncing based on content.
• well defined endpoint sync - when both parties have identical sets.
• allows peer peer architecture, peer can act client or server, providing can host http server.
• sync works content of sets, not abstract concept time.
• since sync built around content, sync can used content verification if desired. e.g. sha-1 hash can computed on content , used uuid. can compared sent during syncing.
• even further, sha-1 hashes can based on previous hashes maintain consistent history of content.

disadvantages of content-based syncing

• extra properties on objects may needed implement.
• more logic on both sides compared timestamp based syncing.
• slightly more chatty protocol (this tuned syncing content in clusters).

i don't know if applies in environment, might consider time "right", client or server (or if matters)? if clients , servers not sync'd same time source there possibility, slight, of client getting unexpected result when syncing (or from) server using client's "now" time.

our development organization ran issues several years ago. developer machines not sync'd same time source server scm resided (and might not have been sync'd time source, developer machine time drift). developer machine several minutes off after few months. don't recall of issues, seems build process tried files modified since time (the last build). files have been checked in, since last build, had modification times (from client) occurred before last build.

it our scm procedures not good, or our scm system or build process unduly susceptible problem. today, of our development machines supposed sync time server has our scm system on it.

again, several years ago , can't recall details, wanted mention on chance significant in case.