考虑到新引入的leap秒，只有1岁（java）的lib如何正确执行UTC时间格式

Question

自1970年1月1日以来，以毫秒表示的时间戳是存储时间戳的常用方法，例如在Java中。

例如：

long timestampUtc = System.currentTimeMillis();

这样的时间戳可以以人类可读的时间格式进行格式化，例如使用此代码

    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 leap秒。如果我在tommorow上面运行代码，则系统上的Java
JRE无法知道该leap秒的介绍，并且会错误地格式化时间（一秒）。

我的假设正确吗？
在不能总是使用最新的JRE的系统中，如何正确格式化时间（例如，在日志文件中）？

背景信息：
这在嵌入式设备中使用，该设备通过GPS同步其系统时钟，而GPS的leap秒数偏移到UTC。

Answer 1

Java和Unix的“ epoch”（自1970年1月1日00:00:00
UTC以来的秒数）都完全忽略了leap秒。他们俩都假设每天（以UTC为单位）精确地是86400秒。验证的简单代码块：

    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个leap秒。

如果需要考虑leap秒，则需要找到一个可以做到这一点的库，或者自己调整一下。