英文:
currentTimeMillis vs Calendar
问题
我一直在开发一个应用程序，为了保存重要的时间信息，我一直在使用 System.currentTimeMillis() 来获取毫秒级别的时间戳。我的所有算法都使用这些毫秒数据，并且日期也是以这些毫秒数据保存的。此外，缓存持续时间是根据这个毫秒时间戳确定的，并且对象日期是从这个毫秒级时间戳格式化而来的。
然而我不确定这是否是一个好的做法。使用 Calendar.getInstace() 是否更好呢？
我已经了解到 currentTimeMillis() 可能是一种不好的做法，因为它可能导致时间数据不一致，但我不明白为什么会这样。
英文:
I have been building out an app and to save important time information I have been using System.currentTimeMillis() to get the timestamps in ms. All my algorithms use this ms data and dates are saved with this ms data. Also duration of cache is determined and object dates are formatted from this millisecond timestamp.
I am unsure if this is a good practice though. Is it better to use Calendar.getinstace()
I have gathered that currentTimeMillis() could be a bad practice as it can lead to inconsistencies in the time data but I don't understand why this is.
答案1
得分: 4
日历始终是不良实践。
Java有3到4个关于时间的API。按引入的顺序：
-
System.currentTimeMillis()
-
（与上述一起）：
java.util.Date，稍后是java.sql.Timestamp和Date。这是非常糟糕的API；此时，这些API中几乎所有的方法都已被弃用，因为它们具有误导性，或者根本不执行它们所暗示的操作，而且无论如何都是巨大的误称。j.u.Date表示的是时间上的一个瞬间，不容易用人类的术语表示。日期在根本上是人类的概念。 -
日历（Calendar）。试图修复这个问题。实际上使情况变得更糟：API具有误导性和令人惊讶的地方（.set(MONTH, 1)会将月份设置为……二月！），而且完全不符合习惯，使用带有“字段”概念的额外参数进行.set/.get，并且具有可变类型）。这个API的实际表现能力仍然有限。
-
JSR310，也称为
java.time。这才是好的API。这个API几乎没有令人惊讶的地方，在时间真正复杂的情况下是复杂的，类型的命名恰当，甚至有j.t.Instant和j.t.ZonedDateTime两者，你几乎可以表达与日期相关的任何事情。
我会说强烈不建议使用j.u.Date或日历（Calendar）。如果你所做的一切只是测量时间上的瞬间，可以继续使用System.currentTimeMillis() - 但是如果您需要以人类可读的形式打印出来（例如：“在2020-07-20 16:34时发生了这件事”），请改用java.time。如果您愿意，也可以放弃currentTimeMillis，改为仅在这些情况下使用j.t.Instant - 根据您的偏好。
英文:
Calendar is always bad practice.
Java has 3 to 4 APIs for time. In order of introduction:
- System.currentTimeMillis()
- (together with the above):
java.util.Dateand sometime later,java.sql.Timestampand Date. This is very bad API; at this point, almost all the methods in these are deprecated because they are misleading or straight up do not do what they suggest they do, and are in any case gigantic misnomers.j.u.Daterepresents an instant in time, not readily representable in human terms. Dates are fundamentally human concepts. - Calendar. An attempt to fix the problem. Actually made it worse: The API is misleading and surprising (.set(MONTH, 1) will set the month to.. Februari!), and is entirely non-idiomatic, using .set/.get with an extra parameter with a 'field' concept, and having mutable types). The actual representational power of this API is still limited.
- JSR310, a.k.a.
java.time. THIS is the good one. This has few surprises, is complex where time ends up being actually complex, the types are properly named, going so far as having bothj.t.Instantandj.t.ZonedDateTime, and you can express virtually anything date-related.
I'd say using either j.u.Date or Calendar is strongly dis-recommended. If all you're doing is measuring instants in time, feel free to stick with System.currentTimeMillis() - but if ever you need to print that in human form (such as: "On 2020-07-20 at 16:34, this happened"), switch to java.time instead. If you prefer, feel free to ditch currentTimeMillis and use j.t.Instant for those purposes instead - your preference.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论