考虑到新引入的闰秒，1岁（java）lib如何正确执行UTC时间格式 [英] How can a 1 year old (java) lib correctly perform an UTC Time formatting, considering a newly introduced leap second

问题描述

自1.1.1970 UTC以来以毫秒表示的时间戳是存储时间戳的常用方式，例如在Java中。

A timestamp expressed in milliseconds since 1.1.1970 UTC is a common way to store timestamps, e.g in Java.

例如：

long timestampUtc = System.currentTimeMillis();

这样的时间戳可以以人的阅读时间格式形成，例如使用这个代码

Such a timestamp can be formated in human readle time format, e.g using this code

    SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.US);
    df.setTimeZone(TimeZone.getTimeZone("UTC"));
    String humanTimeUtc = df.format(new Date(timestampUtc));
    System.out.println(humanTimeUtc);

其中输出： 2014-02-14 14:58:05

现在想象，今天午夜，时间管理员引入了一个新的UTC闰秒。
如果我运行上面的代码tommorow，我的系统上的java JRE不能知道闰秒介绍，并会错误地（1秒）格式化时间。

Now imagine that today at midnight the time administration introduces a new UTC leap second. If I run the code above tommorow, the java JRE on my system cannot know that leap second introduction, and would format the time wrongly (by one second).

我的答案是否正确？

如何在不能始终使用最新JRE的系统中正确格式化时间（例如日志文件）？

Is my asumption correct?
How to correctly format the time (e.g in a log file) in systems that cannot always use an up to date JRE?.

背景信息：

这是在嵌入式设备中使用的，它通过GPS同步其系统时钟，将GPS数量的闰秒偏移到UTC。

Background info:
This is used in an embedded device, which synchronizes its system clock via GPS, having the GPS number of leap seconds offset to UTC.

推荐答案

Java和Unixepoch（1970年1月1日00:00:00 UTC之后的秒数）完全忽略闰秒。他们都假设每天（以UTC为单位）已经完全达到了86400秒。验证一个简单的代码块：

Java and the Unix "epoch" (number of seconds since Jan 1, 1970 00:00:00 UTC) both ignore leap seconds entirely. They both assume every day (measured in UTC) has had exactly 86400 seconds. A simple block of code to verify:

    Calendar c = Calendar.getInstance();
    c.setTimeZone(TimeZone.getTimeZone("UTC"));
    c.set(2014, 0, 1, 0, 0, 0);
    c.set(Calendar.MILLISECOND, 0);
    System.out.println(c.getTimeInMillis());

你会看到从1/1/1970到1/1/2014的秒数是86400的确切倍数（实际上是44年* 365.25天/年* 86400秒/天）;它不应该是因为在这个时间间隔内引入了25个闰秒。

You will see that the number of seconds from 1/1/1970 to 1/1/2014 is an exact multiple of 86400 (it's actually exactly 44 years * 365.25 days/year * 86400 seconds/day); it shouldn't be, because there have been 25 leap seconds introduced in that interval.

如果你需要考虑闰秒，你需要找到一个库将这样做，或者想出自己的调整。

If you need to take leap seconds into account, you need to find a library that will do so, or come up with your own adjustment.

这篇关于考虑到新引入的闰秒，1岁（java）lib如何正确执行UTC时间格式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！