如果我运行以下程序，它解析引用时间间隔为1秒的两个日期字符串并比较它们：
public static void main(String[] args) throws ParseException {
SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
String str3 = "1927-12-31 23:54:07";
String str4 = "1927-12-31 23:54:08";
Date sDt3 = sf.parse(str3);
Date sDt4 = sf.parse(str4);
long ld3 = sDt3.getTime() /1000;
long ld4 = sDt4.getTime() /1000;
System.out.println(ld4-ld3);
}
输出是：
353
为什么是 ld4-ld3 不 1 （正如我所期望的那样，时间的一秒钟差异），但是 353？
如果我将日期更改为1秒后的时间：
String str3 = "1927-12-31 23:54:08";
String str4 = "1927-12-31 23:54:09";
然后 ld4-ld3 将会 1。
Java版本：
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Dynamic Code Evolution Client VM (build 0.2-b02-internal, 19.0-b04-internal, mixed mode)
Timezone(`TimeZone.getDefault()`):
sun.util.calendar.ZoneInfo[id="Asia/Shanghai",
offset=28800000,dstSavings=0,
useDaylight=false,
transitions=19,
lastRule=null]
Locale(Locale.getDefault()): zh_CN
这是12月31日在上海的时区变化。
看到 这一页 有关1927年在上海的详情。基本上在1927年底的午夜，时钟倒流了5分52秒。所以“1927-12-31 23:54:08”实际上发生了两次，看起来Java正在解析它 后来 当地日期/时间的可能瞬间 - 因此差异。
只是在经常奇怪和精彩的时区世界的另一集。
编辑： 停止按！历史变迁......
如果使用版本2013a重建，原始问题将不再表现出完全相同的行为 TZDB。在2013a中，结果为358秒，转换时间为23:54:03而不是23:54:08。
我只是注意到了这一点，因为我正在以Noda Time的形式收集这样的问题 单元测试...测试现在已经改变，但它只是显示 - 甚至历史数据都不安全。
编辑： 历史再次改变......
在TZDB 2014f中，更改的时间已经变为1900-12-31，现在只有343秒变化（因此时间间隔为 t 和 t+1 是344秒，如果你看到我的意思）。
编辑： 回答关于1900年转换的问题......看起来像Java时区实现一样 所有 时区只是在1900年UTC开始之前的任何时刻的标准时间内：
import java.util.TimeZone;
public class Test {
public static void main(String[] args) throws Exception {
long startOf1900Utc = -2208988800000L;
for (String id : TimeZone.getAvailableIDs()) {
TimeZone zone = TimeZone.getTimeZone(id);
if (zone.getRawOffset() != zone.getOffset(startOf1900Utc - 1)) {
System.out.println(id);
}
}
}
}
上面的代码在我的Windows机器上没有输出。因此，任何在1900年开始时具有除标准偏移之外的任何偏移的时区都将其视为过渡。 TZDB本身有一些数据早于此，并且不依赖于“固定”标准时间的任何想法（这是什么 getRawOffset 假设是一个有效的概念）所以其他图书馆不需要引入这种人为过渡。
你遇到了一个 当地时间不连续：
当地标准时间即将到达星期日，1928年1月1日，
00:00:00时钟倒退0:05:52到星期六，31。
1927年12月，当地标准时间23:54:08代替
这并不是特别奇怪，并且由于政治或行政行为导致时区被切换或改变，因此在任何时候都发生过这种情况。
增加时间时，您应该转换回UTC然后加或减。仅使用当地时间进行显示。
通过这种方式，您可以在几小时或几分钟发生两次的任何时段走过。
如果您转换为UTC，请添加每秒，然后转换为本地时间进行显示。你会经过晚上11:54:08。 LMT - 下午11:59:59 LMT然后是晚上11:54:08 CST - 下午11:59:59 CST。
您可以使用以下代码，而不是转换每个日期
long difference = (sDt4.getTime() - sDt3.getTime()) / 1000;
System.out.println(difference);
并看到结果是：
1
我很遗憾地说，但是时间的不连续性已经发生了变化
JDK 6 两年前，在 JDK 7 就在最近 更新25。
需要学习的经验：不惜一切代价避免非UTC时间，可能用于显示。
正如其他人所解释的那样，那里有一段时间不连续。有两种可能的时区偏移 1927-12-31 23:54:08 在 Asia/Shanghai，但只有一个偏移 1927-12-31 23:54:07。因此，根据使用的偏移量，存在一秒差异或5分53秒差异。
这种轻微的偏移转移，而不是我们习惯的通常的一小时夏令时（夏令时），可以稍微模糊一下这个问题。
请注意，时区数据库的2013a更新在几秒钟之前移动了这种不连续性，但效果仍然可以观察到。
新的 java.time Java 8上的包让我们更清楚地看到它，并提供处理它的工具。鉴于：
DateTimeFormatterBuilder dtfb = new DateTimeFormatterBuilder();
dtfb.append(DateTimeFormatter.ISO_LOCAL_DATE);
dtfb.appendLiteral(' ');
dtfb.append(DateTimeFormatter.ISO_LOCAL_TIME);
DateTimeFormatter dtf = dtfb.toFormatter();
ZoneId shanghai = ZoneId.of("Asia/Shanghai");
String str3 = "1927-12-31 23:54:07";
String str4 = "1927-12-31 23:54:08";
ZonedDateTime zdt3 = LocalDateTime.parse(str3, dtf).atZone(shanghai);
ZonedDateTime zdt4 = LocalDateTime.parse(str4, dtf).atZone(shanghai);
Duration durationAtEarlierOffset = Duration.between(zdt3.withEarlierOffsetAtOverlap(), zdt4.withEarlierOffsetAtOverlap());
Duration durationAtLaterOffset = Duration.between(zdt3.withLaterOffsetAtOverlap(), zdt4.withLaterOffsetAtOverlap());
然后 durationAtEarlierOffset 将是一秒钟，而 durationAtLaterOffset 将是5分53秒。
此外，这两个偏移是相同的：
// Both have offsets +08:05:52
ZoneOffset zo3Earlier = zdt3.withEarlierOffsetAtOverlap().getOffset();
ZoneOffset zo3Later = zdt3.withLaterOffsetAtOverlap().getOffset();
但这两者是不同的：
// +08:05:52
ZoneOffset zo4Earlier = zdt4.withEarlierOffsetAtOverlap().getOffset();
// +08:00
ZoneOffset zo4Later = zdt4.withLaterOffsetAtOverlap().getOffset();
您可以看到相同的问题比较 1927-12-31 23:59:59 同 1928-01-01 00:00:00但是，在这种情况下，它是较早的偏移产生较长的偏差，而较早的日期有两个可能的偏移。
另一种方法是检查是否正在进行转换。我们可以这样做：
// Null
ZoneOffsetTransition zot3 = shanghai.getRules().getTransition(ld3.toLocalDateTime);
// An overlap transition
ZoneOffsetTransition zot4 = shanghai.getRules().getTransition(ld3.toLocalDateTime);
您可以检查转换是否是重叠 - 在这种情况下，该日期/时间有多个有效偏移量 - 或间隙 - 在这种情况下，日期/时间对于该区域ID无效 - 通过使用 isOverlap() 和 isGap() 方法 zot4。
我希望这有助于人们在Java 8广泛使用后处理这类问题，或者使用采用JSR 310反向端口的Java 7的人。
恕我直言，无处不在， 含蓄 Java中的本地化是其最大的设计缺陷。它可能适用于用户界面，但坦率地说，今天谁真正使用Java作为用户界面，除了一些IDE，你基本上可以忽略本地化，因为程序员并不完全是它的目标受众。您可以通过以下方式修复它（特别是在Linux服务器上）：
- export LC_ALL = C TZ = UTC
- 将系统时钟设置为UTC
- 除非绝对必要，否则永远不要使用本地化的实现
到了 Java社区流程 我推荐的成员：
- 使本地化方法不是默认方法，但要求用户明确请求本地化。
- 使用UTF-8 / UTC作为 固定 默认，因为这只是今天的默认值。除非您想生成这样的线程，否则没有理由做其他事情。
我的意思是，来吧，不是全局静态变量是反OO模式吗？没有其他东西是由一些基本环境变量给出的普遍违约.......