设置与 System.currentTimeMillis() 的时间差答案

【问题标题】：Settings time difference from System.currentTimeMillis()设置与 System.currentTimeMillis() 的时间差
【发布时间】：2017-05-16 10:51:22
【问题描述】：

我发现了问题所在：

显然http://www.epochconverter.com/ 对输入值的精度做出了假设，并且从这些假设值中，841073068 周围的值可以追溯到 1996/1997。我不确定导致那个确切日期的假设是什么，但老实说我不在乎。

使用附加的调试器，我调用了new Date(System.currentTimeMillis())，它正确地给了我 1070 年 1 月 10 日的日期，这意味着时钟不会像疯了一样跳出。

原问题：

我正在运行一台装有 Android for 和 IoT 案例的单板计算机（https://developer.qualcomm.com/hardware/dragonboard-410c）。运行的操作系统是 Qualcomm 提供的普通 Android。

目前我正在测试一次长时间执行的电路板的可靠性，我看到一些非常奇怪的行为，我无法找到解释。

该板在 10 天前通电，但无法访问互联网（WiFi 已打开，但未设置访问点，也没有以太网）。蓝牙打开了，办公室里有 iBeacons 和 Eddystone。该地区也有WiFi。

如果我现在去Settings -> Date and Time，或查看通知栏或进入时钟应用程序或日历应用程序，我会看到 1970 年 1 月 10 日。这是预期的，基本上显示了董事会运行了多长时间。

它上面的应用程序有一个始终运行的服务，它进行一些数据处理和一些磁盘日志记录（用于调试）。

从日志中，我可以看到 System.currentTimeMillis() 在板最初通电时返回预期值。这意味着，日志的开头表示 1970 年 1 月的纪元时间。

但在日志的末尾（以及在实时进程上附加调试器），System.currentTimeMillis() 的值在 1996 年 9 月/10 月的某个地方。示例值：841073068、841263234、841579239

所以我的问题是：

这里发生了什么？
为什么System.currentTimeMillis() 的值发生了变化，是什么改变了它？
为什么 Android 用户界面（通知、时钟应用程序、设置）仍然显示 1970？他们从哪里获得这个价值？

编辑：

答案有些混乱，我可以看到我的问题缺乏细节。

我不想测量时差。我需要一个实际的时间戳。这些值将通过蓝牙 LE 事件通过 POST 报告给我们的后端。这个“无网络”的东西是我们在板上运行的可靠性测试，但我们确实希望大部分时间都有网络，并且板应该使用正常的 Android 方式从网络自动更新时间。

我只是想了解当前批次的测试，出了什么问题以及为什么。

【问题讨论】：

奇怪的行为，我经常在软件中发现系统时间远不接近实时的错误。我个人倾向于避免到目前为止关闭的系统时间。无论如何，这个问题对于这个论坛来说似乎是题外话。您可能不想向制造商或 Google 发送错误报告。
@Rolfツ我理解您考虑偏离主题的原因，但正如我所见，可能有一些我没有考虑的编程原因。通常我也会消除远时钟，但由于这是对连接不稳定时行为的可靠性测试，因此挖掘并了解系统限制非常重要。

标签： android timestamp unix-timestamp clock dragonboard

【解决方案1】：

好吧，正如您已经知道的那样，当前系统时间 (System.currentTimeMillis()) 可以根据需要由任何进程修改，它完全有可能被另一个进程修改。这不是衡量正常运行时间的可靠方法。

我会使用类似的评价：

SystemClock.uptimeMillis()

哪个returns 自设备启动以来经过的时间（以毫秒为单位）（不包括深度睡眠所花费的时间）。

我还想提一下，我怀疑蓝牙与它有关，我可以想象蓝牙使用系统时间进行配对和安全，就像 SSL 一样（但我不是专家）。 GPS 也可能是个问题，因为 GPS 可用于获取 UTC 时间值，但我不确定您的主板是否有 GPS 模块。

关于您的编辑：

获得一个有效的时间戳会很容易：服务器时间减去你的董事会报告的经过时间。但我建议您要么选择接受System.currentTimeMillis() 报告的时间，要么使用经过的时间。在我工作的公司，我们也使用嵌入式 Android 设备，在我们的服务器仪表板上，我们可以同时看到正常运行时间（从那时起）和当前设备时间，但至少在我看来，它们不应该混为一谈，尤其是因为System.currentTimeMillis() 可能会发生变化，并受夏季和冬季时间的影响。

【讨论】：

我也怀疑蓝牙，但我们的过程没有与任何东西配对，只进行蓝牙 LE 扫描。董事会有 GPS，但我们没有用它做任何事情，它在办公室里，我怀疑它可以得到任何信号。另外请检查我的问题的编辑
感谢您的回答/cmets。请参阅我的问题顶部的编辑，我发现发生了什么。我们不会混淆 uptime 和 currentTimeMilis。但只是我们需要在仪表板上报告扫描事件发生的时间，如果板重新启动或进入睡眠状态都没关系，一般来说，日期应该通过 NTP 正常保存在设备上，就是这样导致 1970 年的网络中断。

【解决方案2】：

如果你想测量一些东西，最好试试System.nanoTime()。这是区别 - https://stackoverflow.com/a/351571/2793494

【讨论】：

感谢您的回答，但这并不是我真正想要的，请阅读我的问题的编辑。 Tl;DR 是。我真的需要时间戳，现在这只是一个测试。
查看我问题顶部的编辑，我发现了发生了什么。