System.currentTimeMillis()是否返回UTC时间？

Question

我想以毫秒为单位获取当前的UTC时间。我搜索了一下google，得到了System.currentTimeMillis()确实返回UTC时间的一些答案。但事实并非如此。如果我做了以下事情:

long t1 = System.currentTimeMillis();
long t2 = new Date().getTime();
long t3 = Calendar.getInstance().getTimeInMillis();

所有三个时间几乎相同(由于通话时间不同，时间相差毫秒)。

t1 = 1372060916
t2 = 1372060917
t3 = 1372060918

这个时间不是UTC时间，而是我的时区时间。如何在android中获取当前UTC时间？

Answer 1

我可以确认所有三个调用都可能取决于本地时间，考虑到纪元，而不是 Date.toString（） 或任何类似的方法。我已经看到它们依赖于运行Android 2.3的特定设备的本地时间。我还没有用其他设备和Android版本测试过它们。在这种情况下，本地时间是手动设置的。

获取独立UTC时间的唯一可靠方法是使用GPS_PROVIDER请求位置更新。从NETWORK_PROVIDER检索的位置的getTime（）值也取决于本地时间。另一个选项是ping返回UTC时间戳的服务器。

所以，我所做的是以下几点：

public static String getUTCstring(Location location) {
    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
    String date = sdf.format(new Date(location.getTime()));
    // Append the string "UTC" to the date
    if(!date.contains("UTC")) {
        date += " UTC";
    }
    return date;
}

Answer 2

您显示的所有三行都将给出自unix历元以来的毫秒数，这是一个固定的时间点，不受本地时区的影响。

你说“这个时间不是UTC时间”——我怀疑你实际上诊断错了。我建议为此使用 epochconverter.com。例如，在您的示例中：

1372060916 = Mon, 24 Jun 2013 08:01:56 GMT

我们不知道您是何时生成该值的，但除非实际上是在世界协调时上午8:01，否则这是您的系统时钟有问题。

都不是＜code＞系统。currentTimeMillis或Date内的值本身都不受时区影响。但是，您应该注意Date。toString（）确实使用了本地时区，这误导了许多开发人员，使他们认为Date与时区有着内在的联系——它不是，它只是一个瞬间，没有关联的时区甚至日历系统。