currentTimeMillis 与日历 [重复]答案

【问题标题】：currentTimeMillis vs Calendar [duplicate]currentTimeMillis 与日历 [重复]
【发布时间】：2020-11-13 14:21:48
【问题描述】：

我一直在构建一个应用程序并保存重要的时间信息，我一直在使用System.currentTimeMillis() 来获取以毫秒为单位的时间戳。我所有的算法都使用这个 ms 数据，并且日期与这个 ms 数据一起保存。缓存的持续时间也被确定，对象日期的格式是从这个毫秒时间戳开始的。

我不确定这是否是一个好习惯。用Calendar.getinstace()是不是更好

我收集到 currentTimeMillis() 可能是一种不好的做法，因为它会导致时间数据不一致，但我不明白为什么会这样。

【问题讨论】：

或者考虑使用 UNIX 时间格式，在您必须处理国际时区的情况下也会有所帮助
您是否将毫秒时间转换为日期和时间？你知道更新的java.time 库吗？
Calendar 及其子类 GregorianCalendar 在未提供显式时间戳时在 System.currentTimeMillis() 的值上初始化。因此没有太多的收获。只要您只需要检查哪个事件首先发生，时间戳作为长值就可以了；当您需要做一些基于人类日历的事情时使用日历，例如日期格式或确定时间戳所在的月份
可能与您有时听到的值不一致的是它基于系统时钟。如果用户将设备时钟更改为 2010 年，您将获得今年的时间戳。但这在标准 JDK 中是难以避免的。如果实际资金取决于时间戳的正确性，您可以对外部时间服务器进行定期检查以确保系统时间正常
您的意思是inconsistent time elapsed in java？库方法的任何选择都不会使您免于使用该方法。顺便说一句，我推荐Instant.now() 用于大多数用途。

标签： java android java-calendar

【解决方案1】：

日历总是不好的做法。

Java 有 3 到 4 个时间 API。按介绍顺序：

System.currentTimeMillis()
（连同上述）：java.util.Date 以及稍后的某个时间，java.sql.Timestamp 和日期。这是非常糟糕的 API；在这一点上，这些方法中的几乎所有方法都已被弃用，因为它们具有误导性或直接不做他们建议的事情，并且在任何情况下都是巨大的误称。 j.u.Date 代表时间的瞬间，用人类的术语不容易表示。日期本质上是人类的概念。
日历。尝试解决问题。实际上更糟糕的是：API 具有误导性和令人惊讶（.set(MONTH, 1) 会将月份设置为.. Februari！），并且完全不习惯，使用 .set/.get 和带有 ' 的额外参数字段的概念，并且具有可变类型）。此 API 的实际表现力仍然有限。
JSR310，又名java.time。这个是好的。这几乎没有什么令人惊讶的地方，它很复杂，时间最终变得很复杂，类型被正确命名，甚至有j.t.Instant 和j.t.ZonedDateTime，你几乎可以表达任何与日期相关的内容。

强烈不推荐使用 j.u.Date 或 Calendar。如果您所做的只是及时测量瞬间，请随时坚持使用 System.currentTimeMillis() - 但如果您需要以人类形式打印（例如：“在 2020 年 7 月 20 日 16:34，这发生了”），改为切换到java.time。如果您愿意，请随意放弃 currentTimeMillis 并使用 j.t.Instant 来代替 - 您的偏好。

【讨论】：

非常感谢您的澄清 :)