2

此代码将 datetime 转换为 unix 时间戳，但是当我检查位于同一时区的墨西哥城和芝加哥的结果时，我得到了不同的结果。

结果是：

2020 年 4 月 3 日星期五 08:45:18 (am) 在美国/墨西哥城 (CST) 时区和

2020 年 4 月 3 日星期五 09:45:18 (am) 在时区 America/Chicago (CDT)

如何解决这个问题呢？

https://www.epochconverter.com/timezones?q=1585925118&tz=America%2FMexico_City https://www.epochconverter.com/timezones?q=1585925118&tz=America%2FChicago

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")
LocalDateTime dateTime = LocalDateTime.parse(2020-04-03 09:45:18, formatter);
ZoneId zoneId = ZoneId.of("CST", ZoneId.SHORT_IDS)
ZoneOffset zoneOffset = zoneId.getRules.getOffset(LocalDateTime.now)
ldt.toInstant(ZoneOffset.of(String.valueOf(zoneOffset))).toEpochMilli //1585925118000
4

1 回答 1

0

不是同一个时区

你的结果说明了这一点：

2020 年 4 月 3 日星期五 08:45:18 (am) 在美国/墨西哥城 (CST) 时区和

2020 年 4 月 3 日星期五 09:45:18 (am) 在时区 America/Chicago (CDT)

提到了两个时区，而不是一个：美国/墨西哥城和美国/芝加哥。两个时区与 UTC 有相同的标准偏移量 -06:00，并且都使用夏令时（夏令时，DST），但它们是不同的时区。

你的结果是正确的

今年（2020 年）夏季时间于 3 月 8 日在美国/芝加哥开始。因此，在您的示例日期 4 月 3 日，观察到了夏令时。这一天在 America/Mexico_City没有观察到夏令时。夏令时直到 4 月 5 日才开始。这种差异解释了为什么墨西哥的时间是 8 点 45 分，而芝加哥的时间是 9 点 45 分。使用底部的链接来验证两个时区中夏令时转换的日期。

什么是时区？

顾名思义，时区是地球上的一个区域，但该概念还包括该区域内的人们观察到的与 UTC 的历史、现在和已知未来的偏移量。

每个时区都有一个区域/城市格式的唯一 ID，该 ID 也用于您使用的 Epoch 转换器的输出中。

CST 不是时区。CST 是一个模棱两可的缩写。正如评论中提到的，它可能指的是中央标准时间、古巴标准时间或中国标准时间。您打算使用中部标准时间，但即使这样也是模棱两可的：它可能指的是北美中部标准时间或澳大利亚中部标准时间。虽然北美中部标准时间是独一无二的、明确的，但它不是一个时区。它是美国/芝加哥和美国/温尼伯时区（以及更多时区）在一年中相对几个月观察到标准时间的时间。一年中的其余时间，上述时区改用中央夏令时间。但是，是的，CST 也在一年中的某些时候在墨西哥城使用。

在 JavaZoneId.of("CST", ZoneId.SHORT_IDS)中为您提供美国/芝加哥时区，因为SHORT_IDS它被定义为这样做。此定义仅出于一个目的：为您提供一种与现在早已过时的TimeZone课程所提供的行为兼容的行为。除非CST出于历史原因在您的程序中使用并且不能（轻易）被放弃，否则您不应使用 this 或SHORT_IDS. ZoneId.of("America/Chicago")如果这是您想要的时区，请使用。

链接

于 2020-05-26T17:06:35.713 回答