持续时间(闰秒)

我需要在固定的日期时间安排代码中的任务。为此，我使用了一个ScheduledExecutiorService，方法是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

要支持闰秒，您需要ThreeTen Extra扩展jar文件。它有专门的UTC和TAI类以及闰秒表。

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

使用我的库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传输闰秒数据。例子见我关于DZone的文章。请注意，Time4J可以完全取代ThreetenBP，但也可以与Java-8互操作（只需将版本更改为v4.x），并提供了许多超出此处问题范围的功能。

附带说明：大多数人显然选择ThreetenBP是为了让将来更容易迁移到Java-8（只是更改一些导入语句）。但你的问题是

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)

抛开格式化和解析方面的一些明显限制不谈，主要问题似乎是时间尺度定义的处理令人困惑。秒的定义在这里取决于上下文。例如，结果"；PT10M0.600600601S"；如果只考虑使用UTC-SLS的转换，则可以，但如果考虑从POSIX通过UTC-SLS到UTC的整个转换，则不可以。如前所述，POSIX时间在闰秒前10分钟定义得很好，因此在闰秒期间POSIX的任何模糊性都不是借口。

请记住，在java.time之外，实际上没有人谈论UTC-SLS，这是Markus Kuhn针对NTP时间服务器或操作系统内核的内部实现提出的（正式过期）建议。相反，像谷歌这样的其他人和企业推出了他们自己不同的飞跃涂抹实现。我看不出UTC-SLS有什么前途。

并且由于CCD_ 4与UTC-SLS无关（老得多），但也被很好地定义用于正常时间戳（遵循Si秒的UTC定义，我们在这里看到了外部IT世界（它不想知道任何关于闰秒或UTC-SLS的信息）和Threeten Extra之间的互操作性问题，这可能会导致计算持续时间的意外差异。

考虑将Quartz与CronTrigger 一起使用

相关内容

最新更新

热门标签：