使用我的库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-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没有人谈论 UTC-SLS，这是Markus Kuhn提出的（正式过期）解决 NTP 时间服务器或操作系统内核的内部实现的提案。相反，像谷歌这样的其他人和企业引入了他们自己不同的跳跃涂抹实现。我看不到 UTC-SLS 的未来。
并且由于java.util.Date与 UTC-SLS 无关（更早），但对于普通时间戳也有很好的定义（遵循 UTC 定义的 Si-second 并限制了闰秒，根本不处理），我们在这里看到外部 IT 世界（不想了解闰秒或 UTC-SLS）和 Threeten-Extra 之间的互操作性问题，这可能导致计算出的持续时间出现意外差异。