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

目录
  • bug的出现
  • bug排查
  • 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的资料请关注我们其它相关文章!

(0)

相关推荐

  • Moment.js常见用法总结

    Moment.js是一个轻量级的js时间处理类库,其使用简单,方便了日常开发中对时间的操作,提高了开发效率. 引用Moment.js npm install moment 常用的方法 1.moment() 获取当前的日期和时间 moment() 获取String的日期和时间 moment(String) 2.获取get 获取当天的年份 moment().get('year') 获取当天的月份 0-11 moment().get('month') 获取当天的日期 moment().get('dat

  • bug分支和feature分支_动力节点Java学院整理

    软件开发中,bug就像家常便饭一样.有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除. 当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交: $ git status # On branch dev # Changes to be committed: # (use "git reset HEAD <

  • 如何利用moment处理时间戳并计算时间的差值

    项目使用nodejs写服务端,有个功能就是统计代理服务器流量,然后把统计的数据通过echarts渲染到页面. 当然统计数据这里用到了 定时器,在使用的是 var schedule = require( 'node-schedule'); 有兴趣的同学可以在npm上搜一搜关于js定时任务的事,其实都大同小异,差不多都是运用corn表达式. 以下是我的 定时从代理服务器获取数据 并存库. schedule.scheduleJob('*/15 * * * * * ', function () { co

  • vue之moment的使用方式

    目录 前言 一.moment是什么? 二.使用步骤(例:默认查询时间24小时之前~当前时间) 三.日期格式 四.new Date() 相关 前言 在日常开发中,我们常常会遇到以下几种场景: 需要对日期进行非标准格式展示,如 :2021年5月11日星期二下午6点42分 需要对日期进行处理,如:要取前24小时的时间 等 在这时候用js原生的new Date()处理就有些麻烦了,因此我们找到了moment这个类库 一.moment是什么? moment 是一个 JavaScript 日期处理类库. 注

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

    目录 bug的出现 bug排查 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排查 由于后端把时间.日期类的字段都定义为了时间

  • 阿里Druid数据连接池引发的线上异常解决

    目录 前言 过程一:定位工作流 过程二:定位JPA的OpenEntityManagerInViewInterceptor 过程三:定位Druid,真正的罪魁祸首 后记: 前言 事件起因:项目使用了activiti工作流,系统是由老的spring mvc项目改造成的spring boot项目,数据库链接池从dbcp切换到druid,新系统上线后,同事多次系统隔一段时间后数据查询就很慢,基本出不来. 由此开始了线上bug排查之路.这个问题从一开始就模糊定位到数据库层面的问题,因为只有和数据相关的操作

  • MySQL的慢日志线上问题及优化方案

    MySQL 慢日志(slow log)是 MySQL DBA 及其他开发.运维人员需经常关注的一类信息.使用慢日志可找出执行时间较长或未走索引等 SQL 语句,为进行系统调优提供依据. 本文将结合一个线上案例,分析如何正确设置 MySQL 慢日志参数和使用慢日志功能,并介绍下网易云 RDS 对 MySQL 慢日志功能的增强. MySQL 参数组功能 网易云 RDS 实例提供了参数组管理功能,可通过参数管理界面查看绝大部分常用的 MySQL 系统参数,用户可了解当前运行值和建议值: 用户还可通过参

  • JS使用Chrome浏览器实现调试线上代码

    前言 之前调试前端bug都是在开发环境中做完并多次测试没有问题之后发布测试环境,验收合格之后发布生产.但生产环境偏偏会有和开发和测试环境不一致的情况,例如测试环境需要加密,而开发环境先不加密,测试环境传给我们的时间格式和生产环境时间格式不一致,数组对象不一致等导致线上生产报错的bug. 为了更好的在线上环境检测到具体的bug,节省我们在本地把地址改为生产的地址并走多一遍流程测试的麻烦,Chrome浏览器dbug测试就显得尤为重要了. 一.定位js代码并标记dbug 首先F12打开控制台,然后选择

  • Git多人协同开发紧急修复线上bug操作指南

    目录 使用场景 解决思路 操作流程 附录:Git使用的小技巧 Git命令别名 总结 使用场景 团队协同开发时,生产环境出现bug,需要紧急修复. 每位同学在本地开发,对应本地的dev分支,本地测试通过后提交到测试环境的dev分支. 测试环境有其他同学提交的代码,正在测试中,无法提交到生产环境的master分支. 以上情况导致我们不能在本地基于dev分支修复bug,因为会和其他同学提交的测试中的代码“撞车”,导致无法及时提及到生产环境. 这个时候如何正确使用Git管理代码呢? 解决思路 首先我们从

  • Java详解线上内存暴涨问题定位和解决方案

    前因: 因为REST规范,定义资源获取接口使用GET请求,参数拼接在url上. 如果按上述定义,当参数过长,超过tomcat默认配置 max-http-header-size :8kb 会报一下错误信息: Request header is too large 可以修改springboot配置,调整请求头大小 server: max-http-header-size: xxx 后果: 如果max-http-header-size设置过大,会导致接口吞吐下降,jvm oom,内存泄漏. 因为tom

  • 滥用@PathVariable导致bug原因分析解决

    目录 前言 复现 3个匹配步骤 1,根据Path精准匹配 2,如果精准匹配没有成功,就开始模糊匹配 3,如果模糊匹配还匹配不上,就返回null 最后 前言 最近测试同学反馈,上周上线的一个功能会偶然性的报404,按理说这个功能在测试环境已经测试通过,也在线上运行了好几天,怎么会突然报错呢. 一开始以为是前端同学请求的接口有误,但是测试又说只是偶然性的404,几率也不高,于是打开日志找到对应的接口,一眼看到了接口上定义的@PathVariable,再一看参数,基本就确定是开发同学为了偷懒又误用@P

  • vue中解决chrome浏览器自动播放音频和MP3语音打包到线上的实现方法

    一.vue中解决chrome浏览器自动播放音频 需求 有新订单的时候,页面自动语音提示和弹出提示框: 问题 chrome浏览器在18年4月起,就在桌面浏览器全面禁止了音视频的自动播放功能.严格地来说,是Chrome不允许在用户对网页进行触发之前播放音频.不光是这样,在页面加载完毕的情况下,用户没有click.dbclick.touch等主动交互行为,使用js直接调用.play() 方法的话,chrome都会抛出如下错误:Uncaught (in promise) DOMException: 解决

  • 线上dubbo线程池耗尽CyclicBarrier线程屏障异常解决记录

    目录 事件背景 问题定位 解决问题 文末结语 事件背景 系统相关使用人员反馈系统故障,日志显示从ams系统服务提示dubbo处理线程不足,具体异常信息如下: 问题定位 从上图可知,dubbo的处理线程池满了,默认200个线程,活动线程也是200个.这个现象非常不正常,我们的应用并发还没有到这个程度能同时占用200个线程处理请求.然后去读了下dubbo源码,发现dubbo也认为这种情况不正常,然后帮我们记录了应用的线程堆栈信息,这个非常赞.代码如下: 上面这段代码,在线程池不够用时,会每隔十分钟输

  • Java集合去重导致的线上问题

    目录 前言: HashSet源码 性能对比 前言: 在工作中一次排查慢接口时,查到了一个函数耗时较长,最终定位到是通过 List 去重导致的. 由于测试环境还有线上早期数据较少,这个接口的性能问题没有引起较大关注,后面频繁超时,才引起重视. 之前看<阿里巴巴Java开发手册>里面有这样一段描述: 如果需要这本书资源的网上下载也行,私聊我发你也行 今天我就结合源码聊聊Set是怎样保证数据的唯一性的,为什么两种去重方式性能差距这么大 HashSet源码 先看看类注释: 看类注释上,我们可以得到的信

随机推荐