1

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.

chrisdottel
  • 1,053
  • 1
  • 12
  • 21
  • or maybe consider using UNIX time format, will help in cases where you have to handle international time zones as well – Samarth Gupta Jul 23 '20 at 19:03
  • 3
    Do you convert the millisecond time to a date and time? Are you aware of the much newer `java.time` libraries? – stdunbar Jul 23 '20 at 19:05
  • 1
    Calendar and it's subclass GregorianCalendar initialize on the value of `System.currentTimeMillis()` when not provided with an explicit timestamp. Therefore there is not much to gain. Timestamps as long values should be fine as long as you only need to check which event occured first; use Calendar when you need to do stuff that is based on a human calendar like date formatting or determining which month a timestamp was in – Roland Kreuzer Jul 23 '20 at 19:08
  • The possible inconsistencies with the value you sometimes hear about is that it is based on the system clock. If the user changes the devices clock to the year 2010 you'll get timestamps of this year. But this is something you can hardly avoid within the standard JDK. If actual money depends on the correctness of the timestamp you could do periodical checks against an external time-server to ensure the system time ok – Roland Kreuzer Jul 23 '20 at 19:19
  • Did you mean [inconsistent time elapsed in java](https://stackoverflow.com/questions/30612464/inconsistent-time-elapsed-in-java)? No choice of library methods will save you from that one. BTW I recommend [`Instant.now()`](https://docs.oracle.com/javase/10/docs/api/java/time/Instant.html#now()) for most purposes. – Ole V.V. Jul 23 '20 at 19:55
  • Does this answer your question? [System.currentTimeMillis() vs. new Date() vs. Calendar.getInstance().getTime()](https://stackoverflow.com/questions/368094/system-currenttimemillis-vs-new-date-vs-calendar-getinstance-gettime). Please search for more and when done, report what more precisely you still haven’t found. – Ole V.V. Jul 23 '20 at 20:41

1 Answers1

4

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.Date and sometime later, java.sql.Timestamp and 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.Date represents 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 both j.t.Instant and j.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.

rzwitserloot
  • 85,357
  • 5
  • 51
  • 72