我有这种情况，我想看看是否有更好的解决方案：
我从系统 A 收到一个时间戳，格式为"yyyy-MM-dd-HH-mm-ss"，没有时区，但他们可以将其修复为 UTC。
然后我需要通过 SSH 连接到系统 B 以获得"上次同步时间"， 这可能是过去，它不返回任何时区，甚至不返回年份(来自备份产品)，下面是一个示例：
"同步时间：周日 11 月 3 日 01：13"
System B 是运行一些专有软件的备份设备，并且有一个内部调度程序每 15 分钟唤醒一次，以检查是否有任何数据需要从源同步。如果上一个同步仍在运行，它将让当前同步完成而不采取进一步操作。此"上次同步时间"将在每次同步后更新，因此在最坏的情况下，它不应落后于当前系统时间超过几个小时。
我需要比较这两个时间戳，以确保 B 上的"上次同步时间"晚于 A。如果没有，我需要等待并重试查询，直到 B 晚于 A 才能继续下一步。
我有一个 Java 程序，当来自 A 的请求传入时，它会向 B 查询"上次同步时间"，然后立即向 B 发出"date"命令以获取当前系统时间，该命令以"EEE MMM dd kk"的格式返回当前系统时间：mm：ss z yyyy"，例如，
"Fri Jun 14 21：07：07 EDT 2019"，
因此程序可以应用此输出的年份和时区来完成"上次同步时间"的时间戳。该程序确实处理"最后 snync 时间"和"日期"输出分布在一年边界上的情况。
它工作正常，除非夏季夏令时结束时，时钟回滚(凌晨 2 点回滚到凌晨 1 点)，有一个小时的窗口时间会模棱两可：
例如，我从系统 A 获得凌晨 1：20 的时间stmap(已经从 UTC 转换为本地)，然后当我从系统 B 获得凌晨 1：30 时， 我无法判断 B 是否晚于 A。可能是时钟变化前的 1：30。系统 B 的当前时区未明确"上次同步时间"位于哪个时区。
我们要求用户将所有系统切换到UTC时间，因此我们无需担心时钟调整。但这对环境的影响太大了。
一种选择是我专门处理一小时，等到"上次同步时间"时间戳超过凌晨 2 点。为此，我需要在代码中检查每次进行时间戳比较时这是否是特定小时，我认为这不是最佳的。但我想不出更好的方法。
任何建议都非常感谢。如果这是要走的路，是否有一个好的 Java 库来计算夏令时的切换日期？谢谢一百万！
我认为您无法完全确定。"太阳11月3日"可能是在2002年，2013年或2019年，甚至更久远的历史。一种方法是，如果可以假设上次同步时间不超过当前系统 B 系统时间之前的几年(也不在该时间之后)，如果可以检测到它不在这几年内，则报告错误。
夏令时(夏令时)结束时的诀窍是，如果有任何歧义，则始终假定较早的时间。这样，当您检测到同步时间晚于 A 的时间戳时，无论如何解释不明确的同步时间，都是如此。这也意味着您将按照您的建议等到凌晨 2 点之后的最后一次同步时间。就比较而言，我不希望这过于昂贵，但如果您需要确定，则需要做出自己的测量和判断。
final DateTimeFormatter timestampFormatter
= DateTimeFormatter.ofPattern("uuuu-MM-dd-HH-mm-ss");
final ZoneId systemBTimeZone = ZoneId.of("America/New_York");
final String syncFormatPattern = "'Sync''ed-as-of time:' EEE MMM d HH:mm";
final DateTimeFormatter currentSystemBTiemFormatter = new DateTimeFormatterBuilder()
.appendPattern("EEE MMM dd HH:mm:ss ")
.appendZoneText(TextStyle.SHORT, Collections.singleton(systemBTimeZone))
.appendPattern(" yyyy")
.toFormatter(Locale.US);
final Period maxSyncAge = Period.ofYears(2);
String systemATimestampString = "2019-11-03-06-05-55";
String lastSyncMsg = "Sync'ed-as-of time: Sun Nov 3 01:13";
String currentSystemBTime = "Sun Nov 03 01:13:07 EDT 2019";
OffsetDateTime systemATimestamp = LocalDateTime.parse(systemATimestampString, timestampFormatter)
.atOffset(ZoneOffset.UTC);
ZonedDateTime maxLastSyncTime
= ZonedDateTime.parse(currentSystemBTime, currentSystemBTiemFormatter);
ZonedDateTime minLatSyncTime = maxLastSyncTime.minus(maxSyncAge);
int candidateYear = maxLastSyncTime.getYear();
ZonedDateTime syncTime;
while (true) {
DateTimeFormatter syncFormatter = new DateTimeFormatterBuilder()
.appendPattern(syncFormatPattern)
.parseDefaulting(ChronoField.YEAR, candidateYear)
.toFormatter(Locale.US);
try {
syncTime = LocalDateTime.parse(lastSyncMsg, syncFormatter)
.atZone(systemBTimeZone)
.withEarlierOffsetAtOverlap();
if (syncTime.isBefore(minLatSyncTime) || syncTime.isAfter(maxLastSyncTime)) {
throw new IllegalStateException("Last sync time is out of range");
}
break;
} catch (DateTimeParseException dtpe) {
// Ignore; try next earlier year
}
candidateYear--;
}
System.out.println("Last sync time: " + syncTime);
System.out.println("Timestamp from system A: " + systemATimestamp);
System.out.println("Is OK? " + syncTime.toOffsetDateTime().isAfter(systemATimestamp));
就代码段而言，它的输出是：
Last sync time: 2019-11-03T01:13-04:00[America/New_York] Timestamp from system A: 2019-11-03T06:05:55Z Is OK? false
您可以看到它已选择将上次同步时间 01：13 解释为夏令时，偏移量为 -04：00，这会导致检查失败。时间也可能是标准时间，偏移量为 -05：00，在这种情况下，UTC 等效项为 06：13，并且检查将成功。但如前所述，为了安全起见，我们宁愿等到 02：00 之后的同步时间并再次变得明确。
while 循环不断解析字符串，假设年份不同，直到它达到星期几匹配的年份。
在马特约翰逊的评论中得到了这个，我认为这是最好的解决方案：
现代Java代码应该使用java.time包，该包自Java 8以来就已内置。ZoneRules.getValidOffsets将告诉您适用于特定时区中给定LocalDateTime的偏移量。如果返回多个偏移量，则表示您处于不明确的时间段。