上下文：
用户提供日期和时间以及特定的UTC偏移量
1994-06-05T08:15:30-05:00
然后通过一些Java日期时间库传递，这些库确定在夏令时期间发生这种情况，并且有助于在偏移量上添加一小时（如果时间戳不是夏令时，则不经修改就返回）： / p>
1994-06-05T08:15:30-04:00（请注意，15:30的时间不会更改
最后，我在前端（javascript）收到该字符串，并且我只需要显示与输入完全相同的原始UTC偏移量，在这种情况下为-05:00。
我无法改变此过程的任何部分，因此我唯一的选择是尝试对夏令时检测进行逆向工程，并在适当时减去一小时的偏移。
由于日期和时间保持不变，一个明显的解决方案是只检查IF date and time are in daylight savings time THEN subtract one hour from offset。对于大多数时间戳，这是有效的，但是在DST边界存在问题，因为例如相同的时间戳可以在DST生效的那天的凌晨1点到凌晨2点发生两次。在给定有关如何生成最终时间戳的信息的情况下，是否有任何方法可用于消除DST边界上发生的部分或全部时间戳的歧义？
答案 0 :(得分：4)
一些事情：
EST是时区缩写，而不是时区。时区将通过其IANA / TZDB标识符来标识，例如America/New_York。
通常，应避免使用时区缩写，因为：
他们可能含糊不清。例如，CST可以是美国中央标准时间（UTC-6），古巴标准时间（UTC-5）或中国标准时间（UTC + 8）。
在世界的某些地方，它们与区域相关联，而不是固定的偏移。例如，MSK已经在俄罗斯莫斯科使用了很长时间。它目前意味着UTC + 3，但过去几年它意味着UTC + 4。
并非所有人都同意使用缩写。例如，夏威夷有时称为HST（夏威夷标准时间），有时称为HAST（夏威夷 - 阿留申标准时间）
世界上并非每个地方都使用英文缩写，甚至根本不使用时区周围的缩写。特别是如果只有一个时区适用于整个国家。
您在后端说过，您已将EST映射到-05:00。这意味着你已经定义了一个表映射时区缩写到偏移量的表。您可能会发现该表具有高度的意见，并且随着您的应用程序随着时间的推移而变得不稳定。我建议不要这样做。
你说你也确定因为DST你增加了一个小时。认识到DST在世界各地的表现各不相同。如果您拥有的是与UTC的偏移量，则无法可靠地确定DST是否有效。此外，这个星球上至少有一个地方（澳大利亚豪勋爵岛），DST切换30分钟，而不是一小时。不要做任何假设。
假设您的意思是美国东部时区，在您提供的那一天1994-11-05，东部时间是美国东部时间（UTC-5）。所以你的例子是错误的，因为你不会在这个日期转移到UTC-4。如果您这样做了，您的缩写无论如何都会更改为EDT - 而不是EST。
由于偏差的使用方式不明确，您无法从偏移回到时区或时区缩写。
UTC-5可以是EST，也可以是ACT，CDT，COT，CST，EASST ，ECT或PET。
UTC-4可以是EDT，也可以是AMT，AST，BOT，CDT，CLT ，COST，ECT，FKT，GYT，PYT或VET。
即使您知道自己仅限于一个国家/地区，并且您只有一个偏移量，但由于DST在某些地方的工作原理，您无法始终确定来自哪个时区。例如，美国的2016-11-06T01:00:00-05:00可能是CDT（America/Chicago），也可能是EST（America/New_York）。两者同时生效。
请查看以下内容：