Question

我需要在固定的日期时间在我的代码中安排任务。为此，我使用ScheduledExecutorService和方法schedule(Runnable command, long delay, TimeUnit unit);

如何根据闰秒计算此延迟？

目前我使用Duration.between()，但它似乎没有意识到闰秒：

ZonedDateTime date1 = ZonedDateTime.of(2015, 06, 30, 23, 59, 59, 000000, ZoneOffset.UTC);
ZonedDateTime date2 = ZonedDateTime.of(2015, 07, 01, 00, 00, 00, 000000, ZoneOffset.UTC);
ZonedDateTime date3 = ZonedDateTime.of(2015, 07, 01, 00, 00, 01, 000000, ZoneOffset.UTC);
System.out.println(Duration.between(date1, date2)); // PT1S
System.out.println(Duration.between(date2, date3)); // PT1S

Answer 1

要支持闰秒，您需要ThreeTen-Extra扩展名jar文件。它有专门的UTC and TAI课程和table of leap seconds。

要计算持续时间，请使用专用的durationUntil()方法。

Answer 2

使用我的库Time4J（v3.x适用于Java 7 - 或Android上的Time4A）将为您提供完整的解决方案，包括对不同时区的格式化和解析的广泛支持。例子：

// Time4J - transformation from old world
Moment m1 = TemporalType.JAVA_UTIL_DATE.translate(d1);
Moment m2 = TemporalType.JAVA_UTIL_DATE.translate(d2);
System.out.println("Time4J - from j.u.Date: " + SI.SECONDS.between(m1, m2)); // 601

// Time4J - programmatical construction of timestamps (like in your example)
m1 = PlainTimestamp.of(2012, 6, 30, 23, 50, 0).atUTC();
m2 = PlainTimestamp.of(2012, 7, 1, 0, 0, 0).atUTC();
System.out.println("Time4J - from utc-timestamps: " + SI.SECONDS.between(m1, m2)); // 601

// Time4J - parsing zoned inputs
ChronoFormatter<Moment> cf =
    ChronoFormatter.ofMomentPattern(
      "d. MMM uuuu HH:mm:ss[XXX]", // optional offset
      PatternType.CLDR, 
      Locale.ENGLISH, 
      EUROPE.PARIS); // only used if the offset is missing in input
m1 = cf.parse("1. Jul 2015 01:50:00");
m2 = cf.parse("1. Jul 2015 09:00:00+09:00");
System.out.println("Time4J - from offsets or zones: " + SI.SECONDS.between(m1, m2)); // 601

// the leap second itself can also be parsed
Moment ls = cf.parse("1. Jul 2015 08:59:60+09:00"); // offset of Tokyo
System.out.println("leap second in 2015: " + ls);
// 2015-06-30T23:59:60Z

还有更多，即支持时钟知道闰秒和从IANA-TZDB传输闰秒数据。示例请参阅我的article on DZone。请注意，Time4J可以完全取代ThreetenBP，但也可以与Java-8互操作（只需将版本更改为v4.x），并提供更多超出问题范围的功能。

旁注：大多数人显然选择ThreetenBP以便将来迁移到Java-8更容易（只需更改一些import语句）。但是你的问题是

Java标准（任何版本）本身对闰秒都不了解（甚至不知道必要的数据）。
建议的其他第三方库Threeten-Extra不支持Java-7。它需要Java-8。

迁移到Java-8后，Threeten-Extra似乎提出了一个解决方案。但是，我现在已经完成了自己的测试，并建议不要使用该库，请参阅以下代码：

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssXXX");
sdf.setTimeZone(TimeZone.getTimeZone("GMT"));
Date d1 = sdf.parse("2012-06-30T23:50:00Z");
Date d2 = sdf.parse("2012-07-01T00:00:00Z");
System.out.println(
  "Old world in Posix - ignorant of leap seconds: " 
  + (d2.getTime() - d1.getTime()) / 1000);
// 600 (OK, SI-seconds without counting leap second, a limitation of POSIX)

Instant instant1 = d1.toInstant();
Instant instant2 = d2.toInstant();
System.out.println(
  "Java 8 without Threeten-Extra: " 
  + (instant2.getEpochSecond() - instant1.getEpochSecond()));
// 600 (obviously using more or less fuzzy "rubber seconds", not SI-seconds)
// internally a simple 1:1-mapping of POSIX is applied within 'toInstant()'

UtcInstant utc1 = UtcInstant.of(instant1);
UtcInstant utc2 = UtcInstant.of(instant2);
System.out.println(
  "Threeten-Extra-impl of UTC-SLS: " 
  + utc1.durationUntil(utc2).getSeconds()); // pitfall, see next output!
// 600 (??? - where is the leap second, should be 601 because of original POSIX-input?!)
System.out.println(
  "Threeten-Extra-impl of UTC-SLS: " 
  + utc1.durationUntil(utc2)); // <= printing the duration object
// PT10M0.600600601S (OK, here the UTC-SLS-specific fraction of second appears
// Reason: Smoothing starts 1000s before leap second)

// only offset "Z=UTC+00:00" can be parsed
utc1 = UtcInstant.parse("2012-06-30T23:50:00Z");
utc2 = UtcInstant.parse("2012-07-01T00:00:00Z");
System.out.println(
  "Threeten-Extra-impl of UTC-SLS: " + utc1.durationUntil(utc2).getSeconds());
// 601 (expected, the only way where seconds are really SI-seconds)

除了格式化和解析方面的一些明显限制外，主要问题似乎是时间尺度定义的混乱处理。第二个的定义取决于上下文。例如，如果您只考虑使用UTC-SLS进行转换，结果“PT10M0.600600601S”是可以的，但如果您考虑从POSIX通过UTC-SLS到UTC的整个转换，则不行。如前所述，POSIX时间在闰秒前10分钟定义良好，因此在闰秒期间POSIX的任何模糊性都不是理由。

请记住java.time以外的真正的NOBODY - 世界谈论UTC-SLS，这是Markus Kuhn提出的{正式过期'提案，解决了NTP时间服务器或操作系统内核的内部实现问题。相反，像谷歌这样的其他人和企业会引入他们自己不同的飞跃涂抹实现。我认为UTC-SLS没有任何未来。

由于java.util.Date与UTC-SLS无关（更老），但也很好地定义了正常的时间戳（在Si-second的UTC定义之后，闰秒的限制不是处理完毕），我们在这里看到外部IT世界（不想知道关于闰秒或UTC-SLS的任何内容）和Threeten-Extra之间的互操作性问题，这可能导致计算持续时间的意外差异。

Answer 3

考虑将Quartz与CronTrigger

一起使用

闰秒持续时间

3 个答案: