java-JWT的发布日期与到期日期检查由于夏令时而失败.全年的永久解决方案是什么？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了java-JWT的发布日期与到期日期检查由于夏令时而失败.全年的永久解决方案是什么？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1920字，纯文字阅读大概需要3分钟。

内容图文

当没有损失的时间或增加的时间要考虑时,该测试通常会全年通过.但是现在这很令人讨厌.我们正在验证过期日期getExp()减去发行日7天,在发布日期getIss()的10毫秒内.由于exp和iss值是紧接彼此产生的10毫秒,因此可以很好地期望delta和iss值介于两者之间.

但是现在可以理解,当Java日期代码在初始化新的JWT Claim之后调用setExp()时,它们距未来一周还有一个小时的路程.

断言/测试代码：

       assertThat(claim.getExp()).isCloseTo(new DateTime(claim.getIss()).plusDays(7).toDate(), 10);

用英文写成：断言索赔的到期日期在索赔的发出日期7天的10毫秒内.

立即解决是在允许的增量中增加一个小时的毫秒数,但是我很好奇是否有更好的解决方案.

编辑：我相信我找到了问题.我们使用ZonedDateTime.now()初始化索赔发布日期和索赔到期日期：

Claim claim = new Claim();
claim.setIss(Date.from(ZonedDateTime.now(ZoneId.of("UTC")).toInstant())); 
claim.setExp(Date.from(ZonedDateTime.now(ZoneId.of("UTC")).plusDays(7).toInstant()));

但是,当我们使用JODA时间进行验证时,我们会采用当地的夏令时规则.显然,这会导致GMT DST与美国DST规则出现问题.

EDIT2：该修复涉及2个单词并更新了单元测试以尊重UTC：

    assertThat(claim.getExp()).isCloseTo(new DateTime(claim.getIss(), DateTimeZone.UTC).plusDays(7).toDate(), 10);

解决方法:

您仅有的两种解决方案是：

>更改报告,以使用UTC(即纪元unix时间),而不是基于本地时间.从技术角度来看,这是首选的解决方案,因为它是包括大多数共享服务器和数据源的全球标准.无需担心DST；而且您仍然可以让您的报告计算本地时间.
>或者,查找或添加可靠的“ dateadd”类型的函数,该函数将夏令时考虑在内.

我一直很惊讶所有平台都没有内置该功能.当然,DST拥有一系列混乱且不断发展的规则,这些规则是特定于区域的(按大陆,国家/地区,某些区域按“州”或“县”划分)…但仍然如此.

目前,在北美大部分地区,DST：

>从三月的第二个星期日开始. (“春季前进”,因此时钟从01:59更改为03:00)
>在11月的第一个星期日结束. (“回退”时间为01:59至01:00)

Windows API具有计算DST是否有效的功能,但实际上,没有应用程序应允许应用程序显示,例如在北美：“ Sunday March 11,2018 02:30:00”,因为该时间不存在.

…但是,#1是您更可取的解决方案,因为准确性和标准化更为简单.

内容总结

以上是互联网集市为您收集整理的java-JWT的发布日期与到期日期检查由于夏令时而失败.全年的永久解决方案是什么？全部内容，希望文章能够帮你解决java-JWT的发布日期与到期日期检查由于夏令时而失败.全年的永久解决方案是什么？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端