Moment的feature导致线上bug解决分析

bug的出现

这一天，本来是平平淡淡的一天，我正准备一如既往的到点下班，结果qa说线上出了个匪夷所思的bug。

表象为：用户在日期选择器选择了1964-01-01之后，自动变成了1963-12-31

我心里想：这是什么神奇bug，于是我又尝试了一下选择1964-01-02、1963-12-31、1965-01-01、1963-01-01，结果都正常，那么到底是为什么会引发这个bug呢?

bug排查

由于后端把时间、日期类的字段都定义为了时间戳，因此前端是有进行一些处理的，可以看下面这个图

从接口中拿到时间戳后，会先存到内存中，格式化后传入antd日期选择器中。每当用户选择日期之后，我会截取日期中的年月日，然后使用moment-timezone去获取到雅加达(印尼首都)当天零点的时间戳，存储到内存中，当用户点击提交的时候，这个时间戳就会被提交到后端去

再来看一下用户选择日期后进行处理的代码

import momentTimeZone from 'moment-timezone';
import moment from 'moment';
import type { Moment } from 'moment';
convert = (value?: Moment | null) => {
        if (value) {
          const valueString = momentTimezone.tz(value.format('YYYY-MM-DD'), 'Asia/Jakarta').format();
          return (moment(valueString).valueOf() / 1000).toFixed();
        }
        return value;
      }

bug的根因

乍一看，没什么问题呀，于是我开始断点，脑溢血的一幕出现了，大家可以去momentjs.com/timezone/do… 这个页面上试一试，百分百复现

// 让人大吃一惊的等式
moment.tz('1961-01-01', 'Asia/Jakarta').format() === '1963-12-31T23:30:00+07:00';

这怎么转换之后，日期还给我整错了呢？我的第一反应就是给moment-timezone提issue，结果没想到有人赶在了我的前面 github.com/moment/mome…

官方也解释的很清楚了：由于当地历史原因，雅加达在1964年之前都是按东七半区来计算时区的，1964年开始才按照东七区来计算，总的来说，这个匪夷所思的等式居然是个feature，只是我使用之前没有了解清楚，所以出了bug，这锅是甩不掉了

解决方案

经过一系列的讨论，我们认为其实日期类型的字段用时间戳表达是不准确的，比如元旦这个节日，在全世界任何一个地区都应该是1月1日，可是如果用时间戳表达的话，可能在某些地区的确是1月1日，但是在其他地区却可能是1月2日了，因此正确的设计应该是用日期字符串来进行存储和传输，比如"2022-01-01"，这样才能避免类似的bug，于是前端、app和be都进行了对应的修改，并且发布了hotfix

虽然影响范围比较小，但是众所周知虾皮对于质量是看的很重的，特别是线上的质量。。。只是可惜了我的绩效。。

好了以上就是Moment的feature导致线上bug解决分析的详细内容，更多关于Moment feature线上bug的资料请关注脚本之家其它相关文章！