我发现了什么问题：
显然http://www.epochconverter.com/假设输入值的精确度，并且从841073068周围的假设值到1996/1997。我不确定导致确切日期的假设是什么，但老实说我并不在乎。
使用附加的调试器我调用了new Date(System.currentTimeMillis())，它正确地给了我一个10月1日到1070年的日期，这意味着时钟不会像疯了一样跳出来。
原始问题：
我正在使用Android for和IoT案例运行单板计算机（此https://developer.qualcomm.com/hardware/dragonboard-410c）。运行的操作系统是高通公司提供的普通Android。
目前，我正在测试电路板的可靠性，以便长时间执行，并且我看到一些非常奇怪的行为，我无法找到解释。
该电路板在10天前启动，无法访问互联网（WiFi已启用，但没有接入点设置，也没有以太网）。蓝牙已经开启，办公室里有iBeacons和Eddystone。该地区还设有WiFi。
如果我现在转到Settings -> Date and Time，或查看通知阴影或输入时钟应用程序或日历应用程序，我会看到1970年1月10日。这是预期的并且基本上显示了电路板运行了多长时间
它上面的应用程序有一个始终运行的服务，它执行一些数据处理和一些磁盘日志记录（用于调试）。
从日志中，我可以看到System.currentTimeMillis()在电路板初次启动时返回了预期值。这意味着，日志的开头表示1970年1月的纪元时间。
但是在日志结束时（以及在实时进程上附加调试器），System.currentTimeMillis()的值在1996年9月/ 10月的某处。示例值：841073068，{{1 }，841263234
所以我的问题是：
841579239值发生了变化？有什么可以改变它？修改
对答案有些困惑，我可以看到我的问题缺乏细节。
我不想衡量时间的差异。我需要一个实际的时间戳。这些值将通过POST到我们的后端通过蓝牙LE事件报告。这个＆＃34;没有网络＆＃34;事情是我们在电路板上运行的可靠性测试，但我们确实希望大部分时间都有网络，电路板应该使用正常的Android方式从网络自动更新时间。
我只是想了解目前的一批测试，出了什么问题以及原因。
答案 0 :(得分：1)
嗯，正如您所知，如果需要，当前系统时间（System.currentTimeMillis()）可以被任何进程修改，它完全可能被另一个进程修改。它不是衡量正常运行时间的可靠方法。
我会评估使用类似的东西：
SystemClock.uptimeMillis()
自设备启动以来经过的时间（以毫秒为单位）returns（不包括深度睡眠所花费的时间）。
我还想提一下，我怀疑蓝牙与它有关，我可以想象蓝牙使用系统时间进行配对和安全就像SSL一样（但我不是专家）。 GPS也可能是一个问题，因为GPS可用于获取UTC时间值，但我不确定您的主板是否有GPS模块。
关于您的修改：
获取有效的时间戳非常简单：服务器时间减去电路板报告的经过时间。但我建议您选择接受System.currentTimeMillis()报告的时间或使用已用时间。在我工作的公司，我们也使用嵌入式Android设备，在我们的服务器仪表板上，我们可以看到正常运行时间（从那时起）和当前设备时间，但它们不应该混合，至少在我看来，尤其是System.currentTimeMillis()会受到变化的影响，并会受到夏季和冬季的影响。
答案 1 :(得分：0)
如果你想衡量一些事情，最好试试System.nanoTime()。这是差异 - https://stackoverflow.com/a/351571/2793494