-1

I am trying to develop an app and there is a Transaction table. In this table, there will be also a date & time field.

In order to keep the transaction time precisely, I think of using java.time.Instant. And whenever I need to convert this to any time zone, I can do it easily and for this reason there will be no problem regarding to time zone. With this approach, I can keep transaction time as a timestamp + solve time zone problem. Is that a true approach?

The second issue id that, do I need to keep another variable for displaying the transaction time properly? Or, is it ok to keep the time as timestamp (java.time.Instant) and display by formatting it when needed. What would you suggest?

Jack
  • 1
  • 21
  • 118
  • 236
  • Some related questions & answers: [What's the difference between Instant and LocalDateTime?](https://stackoverflow.com/q/32437550/12567365), and [Java Best Practice for Date Manipulation/Storage for Geographically Diverse Users](https://stackoverflow.com/q/40075780/12567365). – andrewJames Mar 21 '23 at 13:36
  • @andrewJames Thanks for info, actually I read the first one before and just needed to be clarified about some points. – Jack Mar 21 '23 at 13:49
  • @andrewJames On the other hand, is it a good practice to name Instant field as `timeStamp` for transaction dateTime? Or should I use `date` for the instant field? Any idea? – Jack Mar 21 '23 at 13:50

1 Answers1

2

With this approach, I can keep transaction time as a timestamp + solve time zone problem. Is that a true approach?

If you have a look at the JavaDoc on Instant you'll see that this class indeed represents a single universal point in time with 0 being 12am Jan 1st 1970 UTC. Any point in time can be converted to a localized representation for a certain time zone - the question just will be which time zone it should be.

The second issue id that, do I need to keep another variable for displaying the transaction time properly? Or, is it ok to keep the time as timestamp (java.time.Instant) and display by formatting it when needed.

If you're ok with using the user's own time zone, e.g. someone in the US might see a different time (and even date) than someone in Australia, then you don't need to store anything in addition. Just convert the instant to a ZonedDateTime e.g. via ZonedDateTime.ofInstant(theInstant, theUsersTimeZone) or directly use DateTimeFormatter.

If, however, you need to represent the instant in the form the user causing the transaction saw it, i.e. you need to know whether it was 1pm EST or 1pm CET etc., then you should store the original time zone as well and use that in the conversion.

So what this comes down to is basically a business decision rather than a technical issue: Do your users or your application need to know the time zone the transaction was placed in?

Thomas
  • 87,414
  • 12
  • 119
  • 157
  • Thanks a lot for nice explanations. I understood the following points from your explanations. Could you pls confirm or clarify me? --> – Jack Mar 21 '23 at 12:48
  • **1.** When we save date-time using Instant, that meaning the data is saved based on UTC and can be converted any local time when reading. For example, if the local time (UTC+2) is 14:00 when saving, then it will be kept as 12.00 in UTC. Right? – Jack Mar 21 '23 at 12:51
  • **2.** If the local time when the user saves the data is not important, then we can save data using Instant and can format by using the the approaches you mentioned before displaying. Right? – Jack Mar 21 '23 at 12:52
  • **3.** If 1 and 2 are true, then I think I can use Instant as timestamp and format when displaying. Right? – Jack Mar 21 '23 at 12:53
  • **1.** Basically yes. The instant will be stored as nano-seconds since "epoch" which is 1970-01-01 00:00:00 UTC ( it will actually be stored in 2 fields: seconds since epoch and additional nano seconds). So any instant representing 2pm UTC+2 will represent 12pm UTC. **2.** yes - **3.** since this is "1 & 2" boolean logic turns this into "yes" as well - at least if there are no other considerations :D – Thomas Mar 21 '23 at 12:55
  • Wonderful explanations with funny boolean :D Thanks and marked as answer. Just to have a better idea, could you clarify me about this related to Java Date Time? – Jack Mar 21 '23 at 13:00
  • Can we say that, **in generally**, if we would not mind time zone, then we can use LocalDate / LocalTime or LocalDatetime **AND** if we need time zone just from the reader's perspective (not the place of the operation) and keep as timestamp then use Instant? The rest is ZonedDateTime generally I think (not sure if Momemnt is also so common as ZonedDateTime ) – Jack Mar 21 '23 at 13:03
  • The question about `LocalDateTime` etc. may be a little out of scope here but I'll add a few short thoughts: You should know that those LocalXxx classes _do not_ respresent instants which means those can represent very different points in time and need to be used in a certain common context. That means if time zone really doesn't matter, you might be able to use those classes. However, if you need to sort/order transactions that may be issued from different time zones then you cannot use those unless they always represent the same time zone. – Thomas Mar 21 '23 at 13:17
  • Thank you so much, your explanations like the important summary of a book :) – Jack Mar 21 '23 at 13:22
  • On the other hand, is it a good practice to name Instant field as `timeStamp` for transaction dateTime? Or should I use `date` for the instant field? Any idea? – Jack Mar 21 '23 at 13:50
  • Well, what do the terms "date" and "timestamp" imply? It's up to you but to me "date" would mean a day so "timestamp" would be more accurate :D – Thomas Mar 21 '23 at 14:05
  • Yes, I also thought the same, because it is actually date and time. But when I use imnstant, it does no seem to be a meaningful variable, because this field indicates transaction time. Maybe date is better in this case. – Jack Mar 21 '23 at 14:56