考虑到新引入的闰秒，一个 1 岁的 (java) 库如何正确执行 UTC 时间格式

2022-01-22 00:00:00 time date gps java

自 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 闰秒.如果我明天运行上面的代码，我系统上的 java JRE 无法知道闰秒的引入，并且会错误地格式化时间(一秒).

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 和 Unix 纪元"(自 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());

您会看到从 1970 年 1 月 1 日到 2014 年 1 月 1 日的秒数是 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.

相关文章