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的资料请关注阿兔在线工具其它相关文章！
