测试基础 关于一个时区转换的 BUG

JoyMao · 2022年07月22日 · 最后由 Jerry li 回复于 2022年07月25日 · 2753 次阅读

背景

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

复盘

  • 新上的一个功能列表,里面的时间字段也是此规则。当然,开发说时间都是使用统一的时间转换工具将北京时间进行转的,不用太担心转换问题;而且,当时手头测试的用户正好是加州,显示的 PST 时区时间也针对夏令时做了对应正确的处理,就第 1 时间没去细纠。
  • 正好有另一个需求要验用户设置,就随手改成纽约。顺手瞥了一眼那个列表,时间已经是 EST 了,貌似根据地区做处理了啊,但一细想,(冬天时) PST 跟 EST 不是相差 3 小时吗,怎么现在只有 2 小时。
    网上转换举例:

    实际页面上:

  • 检查其他地方,一样有情况。检查了此工具的代码:开发根据州得到的时区是 “EST“然后转换时间格式,没有什么特殊处理,但为啥没有像 PST 一样自动进行夏令时的调整呢?

原因

  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“来显示,也不纠结是否夏令时了

我在【TesterHome 系列征文活动 | 有意思的 bug】等你,一起 day day up!

共收到 5 条回复 时间 点赞
仅楼主可见
兔子🐰 回复

OK

有个疑问,这种解决方案,能适配到夏令时结束的场景吗? 比如说夏令时结束了,时钟要往回拨一个小时,能保证到时这个问题不会再出现?

我们之前也有遇到过类似的坑。我们当时是用的一个 Timezone 的 jar 包,直接通过城市格式来获取当地的时间。但是后来出现一个 bug ,就是在某一天开始获取的时区不对。后来排查发现,是那个国家的夏令时开始时间提前了,但是那个 jar 包里面还是旧的。通过升级 jar 包版本,解决了这个问题。
所以后来的工作之一,就是要确保这个 jar 包有更新的时候要及时更新部署,以获取最新的时区数据。

Jerry li 回复

使用 UTC 就不用考虑这个夏令时了

JoyMao 回复

使用什么时区是根据业务决定的啊,比如现在需要统计巴西的用户每天的数据,就要以巴西的时区作为零点进行统计,这里就会涉及到夏令时的问题。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册