android - Firebase 实时数据库 key 生成对于 Android/iOS 设备上的时钟更改是否可靠？ #AskFirebase

Question

TL;博士

Firebase Realtime Database使用带有 chronological prefix 的推送 ID ，因此新对象总是按其创建时间戳排序。

在 Android 上启用了离线功能和 iOS应用程序，如果用户已禁用自动时钟同步，SDK 将:

1. 检测变化并在连接恢复时调整前缀？
2. 遵守时钟变化并创建一个带有坏前缀的 ID？

详情

The Bolsonaro's Daylight Saving Time Bug

巴西政府在 2019 年取消了夏令时，但没有给运营商适当的时间，互联网提供商也没有做好准备。因此时钟自动提前，由于时间戳不一致导致巴西的几个分布式系统崩溃。这种现象被称为Bolsonaro's Bug。 .

因为他们不再收到客户的订单而绝望，他们关闭了自动时钟调整并手动设置，依赖移动设备工作的用户(例如出租车司机、送货员等)关闭了自动时钟在他们的设备上更新时钟，并在 1 小时内手动将他们的 block 调回。因此:

1. 如果您住在里约热内卢，GMT-3 会在夏令时更新为 GMT-2，但 UTC不会改变(到目前为止，一切都很好)。
2. 关闭自动更新并手动减去 1 小时以修复 bug 弄乱了设备 UTC，即比真实 UTC< 晚 1 小时/strong>.

问题

当用户离线保存数据(使用坏时钟)并在数小时后尝试与服务器同步时，该场景会出现问题。

由于 Firebase 实时数据库有 offline capabilities和 push IDs are chronologically sorted ，在这种非常具体的情况下，是否可以:

1. 将此延迟通知 SDK 到正确的 UTC 时间？
2. 帮助 SDK 修复离线生成的推送 ID 并更新它们的时间戳前缀？

Answer 1

就时间顺序而言，不准确的本地时钟可能会导致不准确的推送 ID。如果您需要准确的时间来进行排序，我不会过分依赖推送 ID 的排序。

您可能想阅读有关 clock skew 的文档有关如何处理可能的时差的更多信息:

While firebase.database.ServerValue.TIMESTAMP is much more accurate, and preferable for most read/write operations, it can occasionally be useful to estimate the client's clock skew with respect to the Firebase Realtime Database's servers. You can attach a callback to the location /.info/serverTimeOffset to obtain the value, in milliseconds, that Firebase Realtime Database clients add to the local reported time (epoch time in milliseconds) to estimate the server time. Note that this offset's accuracy can be affected by networking latency, and so is useful primarily for discovering large (> 1 second) discrepancies in clock time.

DatabaseReference offsetRef = FirebaseDatabase.getInstance().getReference(".info/serverTimeOffset");
offsetRef.addValueEventListener(new ValueEventListener() {
    @Override
    public void onDataChange(@NonNull DataSnapshot snapshot) {
        double offset = snapshot.getValue(Double.class);
        double estimatedServerTimeMs = System.currentTimeMillis() + offset;
    }

    @Override
    public void onCancelled(@NonNull DatabaseError error) {
        Log.w(TAG, "Listener was cancelled");
    }
});