Last Writer Wins
Resolving a conflict by keeping the version with the later timestamp — simple, deterministic, and it silently discards the other change.
Two devices edit the same record while neither can see the other. On synchronisation, one version must be chosen. Last-writer-wins picks by timestamp: simple to implement, deterministic, and it loses data by design.
Whether that is acceptable depends entirely on what the field means. A user's display-name preference is fine — the later intention is the current one. A shared document, a stock count, or a set of items added to a list is not: the earlier change was real work, and it disappears without any indication that it existed.
There is a second, less obvious hazard: the timestamp is the device's clock, and device clocks are wrong. A phone several minutes ahead wins every conflict it participates in, regardless of the actual order of events. Using a server-assigned timestamp fixes the ordering and requires the server to be reachable, which defeats the offline case; a logical clock — a version vector — orders events without wall time and is the correct answer where ordering matters.
The alternatives, in increasing cost: merge per field rather than per record, so two devices changing different fields both succeed; use a data type that converges without discarding; or surface the conflict to the user, which is honest and is only tolerable if conflicts are rare.