bug的出現(xiàn)

這一天，本來是平平淡淡的一天，我正準備一如既往的到點下班，結果qa說線上出了個匪夷所思的bug。

表象為：用戶在日期選擇器選擇了1964-01-01之后，自動變成了1963-12-31

我心里想：這是什么神奇bug，于是我又嘗試了一下選擇1964-01-02、1963-12-31、1965-01-01、1963-01-01，結果都正常，那么到底是為什么會引發(fā)這個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的根因

乍一看，沒什么問題呀，于是我開始斷點，腦溢血的一幕出現(xiàn)了，大家可以去momentjs.com/timezone/do… 這個頁面上試一試，百分百復現(xiàn)

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

這怎么轉換之后，日期還給我整錯了呢？我的第一反應就是給moment-timezone提issue，結果沒想到有人趕在了我的前面 github.com/moment/mome…

官方也解釋的很清楚了：由于當?shù)貧v史原因，雅加達在1964年之前都是按東七半區(qū)來計算時區(qū)的，1964年開始才按照東七區(qū)來計算，總的來說，這個匪夷所思的等式居然是個feature，只是我使用之前沒有了解清楚，所以出了bug，這鍋是甩不掉了

解決方案

經過一系列的討論，我們認為其實日期類型的字段用時間戳表達是不準確的，比如元旦這個節(jié)日，在全世界任何一個地區(qū)都應該是1月1日，可是如果用時間戳表達的話，可能在某些地區(qū)的確是1月1日，但是在其他地區(qū)卻可能是1月2日了，因此正確的設計應該是用日期字符串來進行存儲和傳輸，比如"2022-01-01"，這樣才能避免類似的bug，于是前端、app和be都進行了對應的修改，并且發(fā)布了hotfix

雖然影響范圍比較小，但是眾所周知蝦皮對于質量是看的很重的，特別是線上的質量。。。只是可惜了我的績效。。

好了以上就是Moment的feature導致線上bug解決分析的詳細內容，更多關于Moment feature線上bug的資料請關注腳本之家其它相關文章！

最新評論