Moment的feature導(dǎo)致線上bug解決分析
bug的出現(xiàn)
這一天,本來是平平淡淡的一天,我正準(zhǔn)備一如既往的到點下班,結(jié)果qa說線上出了個匪夷所思的bug。
表象為:用戶在日期選擇器選擇了1964-01-01之后,自動變成了1963-12-31
我心里想:這是什么神奇bug,于是我又嘗試了一下選擇1964-01-02、1963-12-31、1965-01-01、1963-01-01,結(jié)果都正常,那么到底是為什么會引發(fā)這個bug呢?
bug排查
由于后端把時間、日期類的字段都定義為了時間戳,因此前端是有進(jìn)行一些處理的,可以看下面這個圖
從接口中拿到時間戳后,會先存到內(nèi)存中,格式化后傳入antd日期選擇器中。每當(dāng)用戶選擇日期之后,我會截取日期中的年月日,然后使用moment-timezone去獲取到雅加達(dá)(印尼首都)當(dāng)天零點的時間戳,存儲到內(nèi)存中,當(dāng)用戶點擊提交的時候,這個時間戳就會被提交到后端去
再來看一下用戶選擇日期后進(jìn)行處理的代碼
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… 這個頁面上試一試,百分百復(fù)現(xiàn)
// 讓人大吃一驚的等式 moment.tz('1961-01-01', 'Asia/Jakarta').format() === '1963-12-31T23:30:00+07:00';
這怎么轉(zhuǎn)換之后,日期還給我整錯了呢?我的第一反應(yīng)就是給moment-timezone提issue,結(jié)果沒想到有人趕在了我的前面 github.com/moment/mome…
官方也解釋的很清楚了:由于當(dāng)?shù)貧v史原因,雅加達(dá)在1964年之前都是按東七半?yún)^(qū)來計算時區(qū)的,1964年開始才按照東七區(qū)來計算,總的來說,這個匪夷所思的等式居然是個feature,只是我使用之前沒有了解清楚,所以出了bug,這鍋是甩不掉了
解決方案
經(jīng)過一系列的討論,我們認(rèn)為其實日期類型的字段用時間戳表達(dá)是不準(zhǔn)確的,比如元旦這個節(jié)日,在全世界任何一個地區(qū)都應(yīng)該是1月1日,可是如果用時間戳表達(dá)的話,可能在某些地區(qū)的確是1月1日,但是在其他地區(qū)卻可能是1月2日了,因此正確的設(shè)計應(yīng)該是用日期字符串來進(jìn)行存儲和傳輸,比如"2022-01-01",這樣才能避免類似的bug,于是前端、app和be都進(jìn)行了對應(yīng)的修改,并且發(fā)布了hotfix
雖然影響范圍比較小,但是眾所周知蝦皮對于質(zhì)量是看的很重的,特別是線上的質(zhì)量。。。只是可惜了我的績效。。
好了以上就是Moment的feature導(dǎo)致線上bug解決分析的詳細(xì)內(nèi)容,更多關(guān)于Moment feature線上bug的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
umi插件開發(fā)仿dumi項目自動生成導(dǎo)航欄實現(xiàn)詳解
這篇文章主要為大家介紹了umi插件開發(fā)仿dumi項目自動生成導(dǎo)航欄實現(xiàn)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-01-01