将时区的短标识转换为ZoneId

Question

我正在集成的客户端API以短ID（3个字母的ID）形式返回带有时区的时间，例如：

9:00 MST
13:30 EDT
17:00 MDT

我知道这是不好的做法（尤其是在夏令时期间），应该避免使用短id，但不幸的是我没有办法让客户端改变他们的api。有没有一种简单的方法将这些短id转换为属性ZoneId？ZoneId.SHORT_IDS看起来最接近，但它不包括夏令时。最坏的情况下，我认为我可以自己创建一个短id到ZoneIds的映射表，因为它只限于美国。

- Naty722

---

那么 9:00 MST - 是 America/Denver 还是 America/Phoenix？它们都使用 "MST"，但是丹佛只在非夏令时使用它，而凤凰城全年使用。HAST 也是一样 - 可能是 America/Adak（使用夏令时）或 Pacific/Honolulu（不使用夏令时）。 - Matt Johnson-Pint

我会选择构建自己的地图。在与客户确认CDT始终指古巴夏令时而不是中部夏令时，或者反过来之后，再确定他们是否接受所有的错误和不准确性。因为你永远无法避免这些问题。如果时间总是假定落在附近的日期上，您可以考虑添加一些启发式规则，以便在标准时间期间MST表示美国/丹佛，而在夏季期间表示美国/菲尼克斯。您可能能够获得75％的正确率。 - Ole V.V.

Answer 1

带时区的时间没有意义

13:30 EDT

仅有时间和时区是没有实际意义的。如果没有日期的上下文，这里就没有真正的含义。

SQL-92标准声明了一个TIME WITH TIME ZONE类型，但却没有定义其含义。我不是唯一对SQL委员会的意图感到困惑的人。而且，更重要的是，该数据类型是一个误称：当他们说“时区”时，SQL标准的意思是偏移量。

Java提供了一个OffsetTime类。我认为这个类仅存在于通过JDBC映射到那个混乱的SQL类型TIME WITH TIME ZONE。Javadoc并没有真正解释这个类的含义。

那么你的目标是什么？我建议您编辑您的问题，以指示您打算如何处理此类输入。也许我们可以从那里为您提供指导。

伪时区不唯一

你问道：

有没有一种简洁的方法将这些短ID转换为属性ZoneId？

没有。

这些2-4个字符的伪时区未定义，未标准化，也不唯一。

• CST — 你是指美洲的中央标准时间吗？还是指中国标准时间？或者是古巴标准时间？
• IST — 你是指印度标准时间吗？还是指爱尔兰标准时间？
• PST — 太平洋标准时间还是皮特凯恩标准时间？
• BST — 孟加拉标准时间，布干维尔岛标准时间，还是英国夏令时？
• AMST — 亚马逊夏令时还是亚美尼亚夏令时？

因此，您无法从伪时区中清晰地确定时区。您只能猜测。如果您确定了可能接收到的值的域，并且确定了它们的实际预期时区，则可以创建自己的映射。

但即使如此，在Java中也没有类或在SQL中没有数据类型来表示带有时区的日期。您需要将该时区转换为相对于UTC的偏移量。而对于该转换，您需要一个日期来确定人们在该时区使用的偏移量的时刻……这将使我们回到本答案顶部的点：仅具有区域（或偏移）的时间，但没有日期上下文是没有意义的。

拒绝无意义的数据

您说：

但不幸的是，我无法让客户更改其API

提供带有模糊伪时区的一天中的某个时间就像提供标记为“美元”的金额，同时要求将其转换为“法郎”一样。

• 我们不知道“dollar”是指加拿大元（CAD），美元（USD）还是澳大利亚元（AUD），或者其他二十种带有该名称的货币。
• 我们不知道franc是指西非的CFA法郎，瑞士法郎Swiss franc，还是其他带有该名称的货币。
• 我们没有日期可以查找汇率。

那么你会如何处理这样的请求？你能做什么？你要么必须要求更明确的定义，要么就必须拒绝请求。

- Basil Bourque