
[toc]
默认情况下,Moment Timezone会缓存检测到的时区,也就是后续调用 momenttzguess() 将始终返回相同的值(即使在两次调用中已经更改了时区)。
要忽略缓存并使用新值覆盖缓存,需要调用带参数的方法:
使用方法: momenttz(, String) ,最后一个参数String是时区标识符:
创建的时刻具有不同的UTC时间,是因为这些时刻是在不同的时区创建的。
使用方法: moment()tz(String) ,String是时区标识符:
首先 moment('2021-08-20 10:00:00') 即在默认时区中创建对象,然后 tz(String) 将其时区更改为指定的时区
创建的时刻具有相等的UTC时间,因为这些时刻是在默认时区中创建的
注意:上面两种方法得到不同结果的原因是因为传入的时间字符串 '2021-08-20 10:00:00' 本身是没有时区标识的,所以在转换的时候不同方法会加上不同的时区标识导致的差异,但是如果传入的时间本身就是能明确时间的 时间戳 、 UTC时间('2021-10-31T07:01:00Z') 的话,这两种方法得到的结果就是一样的了。
注意:小写z格式化标记并不总是显示缩写的时区名称,而是显示每个区域的时间偏移。
注意:后续调用 momenttzsetDefault 不会影响现有moment对象或其克隆。
官方文档
需求1:用后台返回的发货时间,减去现在的时间,告诉用户还有多长时间发货, 例如1天24小时36分
afterMomentformat('YYYY-MM-DD HH:mm:ss')) => 2020-06-30 16:10:40
或者
因为 moment()valueOf() 可以得到毫秒数,而 + 、 - 这种 *** 作会隐式调用 valueOf
然后利用 momentduration 提供的 durationdays() 或者 durationget('day') 这两种方式达到格式化
后台提供的时间格式 moment 构造器都是支持的,可惜的是 momentduration 不能直接调用 format 方法
需求2:如果距离发货时间不到12小时,要标红处理
clone() 方法是十分重要的,不然默认会在原对象上处理,会影响到 durationdays() 的值,有时候你可能并不会发现
asMilliseconds 是转化为毫秒,类似的方法还有 asDays 、 asHours 等
或者
这一战好像回到了解放前,把大大小小的坏习惯都犯了一遍,想想之前自己因为通读了一遍moment中文网还写了两篇文章,结果现在还是这个鬼样子,究其原因,无非是掉以轻心,问题并未简单的解决后便自乱阵脚,十成功力散去七八成,俨然成了个弱智
不过当我写这篇文章的时候又发现了更为简单的写法, 过去的自己总是菜的,不进步就会一直菜。
在实际工作中,还是建议先解决问题在逐步优化,针对当前主要矛盾全力以赴,这样大脑和心脏才不会打架,解决问题也会变得高效。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)