我正在尝试使用 caldav 和同步报告实现 syn，但是我遇到了有关如何在多个客户端和服务器之间同步一个日历（一个 VEVENT）的概念问题。
大多数 rfc 都是指使用 etag 来确定资源自上次同步以来是否发生了变化。 （如果 etag 发生更改，则资源自上次同步以来已更改）。 我明白了。 但是，我如何知道哪个更改是最近的？
例如，客户端 A 有一个 "X"，最后编辑时间为凌晨 1 点，它们在上午 8 点同步。 客户端 B 也有一个 ical X 版本，他们在凌晨 2 点编辑并在早上 7 点同步。 所以 B 比 A 和 B 在 A 之前同步更新。
当 A 同步时，它将看到 B 的较新版本的 X。 从 etag 中它知道 X 已经改变，但不知道"何时"。 我假设 A 应该用 B 覆盖，因为 B 是较新的（或者至少能够提示用户说 B 较新）....这个假设是否正确/是否有处理这种情况的标准方法？
通常，问题是在尝试找出服务器和客户端之间哪个文件较新时。etag 只能检测"已更改"，而不能检测"较新"。 上次修改日期似乎反映了客户端上的上传日期，而不是其上次编辑日期。 这让我相信我错过了一些东西。 是否有一些普遍接受的同步算法？
最后的编辑日期只是这里等式的一部分。更有意义的是实际的修改。您可能已关闭设备 B 的闹钟（微不足道的更改），但更改了设备 A 的开始日期（重大更改）。因此，一个表现良好的客户应该尽最大努力尝试将两者合并。有些客户端只会通知您事件已被编辑，并会询问您要保留哪个副本，但没有并排比较 UI，这确实让最终用户感到困惑。如果没有合并机制，我只会忽略 etag 并始终覆盖。
最后，您还应该担心事件的时间表标记（请参阅 https://www.rfc-editor.org/rfc/rfc6638#section-3.2.10）。
iCal文件应包含序列号（每次编辑时递增），该序列号比编辑日期更重要。通过比较 SEQUENCE，如果双方的值不相等，至少您可以决定哪个编辑是更新的。