上下文：
用户提供日期和时间以及特定的 UTC 偏移量
1994-06-05T08:15:30-05:00
然后通过一些 Java 日期时间库传递它，这些库确定这发生在夏令时，并有助于在偏移量上添加一个小时(如果时间戳不在夏令时，则返回而不进行修改)：
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 边界上出现的部分或全部时间戳的歧义？
几件事：
-
EST是时区缩写，而不是时区。 时区将由其 IANA/TZDB 标识符标识，例如America/New_York。 -
通常，应避免使用时区缩写，因为：
-
它们可能是模棱两可的。 例如，
CST可以是美国中部标准时间 (UTC-6)、古巴标准时间 (UTC-5) 或中国标准时间 (UTC+8)。 -
在世界的某些地区，它们与一个区域相关联，而不是固定的偏移量。 例如，
MSK在俄罗斯莫斯科已经使用了很长时间。 它目前的意思是UTC+3，但在过去的几年里，它意味着UTC+4。 -
并非每个人都同意使用缩写。 例如，夏威夷有时称为
HST(夏威夷标准时间)，有时称为HAST(夏威夷-阿留申标准时间) -
并非世界上每个地方都使用英文缩写，甚至根本不使用时区周围的缩写。 特别是如果只有一个时区适用于整个国家/地区。
-
-
你说在后端你
EST映射到-05:00. 这意味着您在某处定义了一个表，将时区缩写映射到偏移量。 您可能会发现该表非常固执己见，并且随着应用程序随着时间的推移而维护，可能会不稳定。 我建议不要这样做。
你 说你还确定，由于夏令时，你增加了一个小时。 认识到世界各地的 DST 都不同。 如果您所拥有的只是与 UTC 的偏移量，则无法可靠地确定 DST 是否有效。 此外，地球上至少有一个地方(澳大利亚豪勋爵岛)将夏令时切换 30 分钟，而不是一小时。 不要做任何假设。
假设你指的是美国东部时区，那么在你给出的那天，
1994-11-05，东部时间是EST(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)。 两者同时生效。
请查看以下内容：
- 时区标签维基(特别是"时区！=偏移量")
- 维基百科的时区缩写列表
- 维基百科关于TZ数据库的条目，以及TZ数据库标识符列表
- Moment-timezone，一个附加的 moment.js允许您在 JavaScript 中使用 IANA/TZDB 时区。
- 夏令时和时区最佳实践文章位于 StackOverflow 上。