关于一个时区转换的 BUG

背景

因为主营业务针对美国，所以网站内的时间格式会根据用户设置的州来显示对应的时区格式，如：PST、EST....

复盘

• 新上的一个功能列表，里面的时间字段也是此规则。当然，开发说时间都是使用统一的时间转换工具将北京时间进行转的，不用太担心转换问题；而且，当时手头测试的用户正好是加州，显示的 PST 时区时间也针对夏令时做了对应正确的处理，就第 1 时间没去细纠。

• 正好有另一个需求要验用户设置，就随手改成纽约。顺手瞥了一眼那个列表，时间已经是 EST 了，貌似根据地区做处理了啊，但一细想，(冬天时) PST 跟 EST 不是相差 3 小时吗，怎么现在只有 2 小时。
  网上转换举例：
  

  

  
  实际页面上：
  

  

  文章源自玩技e族-https://www.playezu.com/188317.html

• 检查其他地方，一样有情况。检查了此工具的代码：开发根据州得到的时区是 “EST“然后转换时间格式，没有什么特殊处理，但为啥没有像 PST 一样自动进行夏令时的调整呢？文章源自玩技e族-https://www.playezu.com/188317.html

原因

1. 查询网上，有人同样的问题：

   

2. 下面的答复：

   

   大致意思：EST 是固定按 UTC-5 处理的，因为这个时区划分范围中，部分国家（加拿大、墨西哥...）的地区是不用夏令时的。如果要体现出夏令时，最好是传入带地区时区标识，比如"US/Eastern" 、 "America/New_York"。
3. 从上面答复来看，这里使用 EST 的话，貌似理论程序上没错，但咨询美国同事，确实是 BUG。 夏季应该用 EDT，这个是一种习惯用法： “ET 在夏季月份（summer months) 采用 EDT, 在其余月份采用 EST 时区，所以 EDT 和 EST 是不会同时存在的。”

处理

• 但针对性改成"US/Eastern" 、 "America/New_York"这种类型传入，工具类方法改动比较大，开发怕影响大
• 最后采用了取巧法，通过州是能获取了另一种时区标识” UTC“类型的，那就直接使用” UTC-5“来显示，也不纠结是否夏令时了

  

我在【玩技博客 系列征文活动 | 有意思的 bug】等你，一起 day day up！文章源自玩技e族-https://www.playezu.com/188317.html51testing软件测试论坛文章源自玩技e族-https://www.playezu.com/188317.html文章源自玩技e族-https://www.playezu.com/188317.html