-1

The Epoch time is universal, no matter where you live, the epoch time shall remain the same.

In Java, you can use calendar, date and LocalDateTime to fetch the current time.

Will the Time in Millis for the date and time calculated by java be the same where ever you are on earth? Or will they differ based on the time zone, you are currently in?

The reason for this question being, my current application needs to process dates for different timezones in parallel. If I use a specific zone, the application results are not in sync wrt other time zones.

Any advice on how to solve this issue?

Eg: Say, A customer buys a product in US on 1'st Jan 2020, at 6:00 AM. In server's timezone, the date itself is different and this transaction doesn't get processed in Singapore time zone, for 2019, as the offset is over 18 hours. However, the transaction gets processed for the year 2018.

I see the following possible solutions. Any advice on how to proceed further?

-> Configure the timezone for MySQL connection, to ensure you always have the right date and time as per the transaction while processing. However, this might not function for Windows server.

-> Add the offset hours and minutes to the time, permanently, so, no further calculations are needed throughout the code.

-> Modify the whole code to use timezone everywhere and use the date, hours and minutes everywhere, to ensure you are processing the right transaction.

Arvind Kumar Avinash
  • 71,965
  • 6
  • 74
  • 110
kris
  • 153
  • 1
  • 7
  • 3
    Does this answer your question, in whole or in part? [Java Best Practice for Date Manipulation/Storage for Geographically Diverse Users](https://stackoverflow.com/questions/40075780/java-best-practice-for-date-manipulation-storage-for-geographically-diverse-user) – Ole V.V. Sep 06 '20 at 11:50
  • Processing Java milliseconds is outdated. I recommend you use an `Instant` from [java.time, the modern Java date and time API,](https://docs.oracle.com/javase/tutorial/datetime/) for a point in time independently of time zone. The general recommendation is to keep your times in UTC in your database. The MySQL `timestamp` datatype is good for that. – Ole V.V. Sep 06 '20 at 11:53

1 Answers1

2

I suggest:

  • In Java use Instant for a point in time. It’s independent of time zone (just like epoch time. It’s an object rather than a naked long value. It prints in UTC, which is more readable than a count of seconds.
  • In MySQL use the timestamp datatype. This is a timestamp in UTC, so also unaffected by the time zone of the database server or connection.

Only for input and output convert to and from a ZonedDateTime for the date and time in a specific time zone. I don’t remember whether the MySQL JDBC driver accepts an Instant for storage; if not, convert to an OffsetDateTime in UTC before storing. MySQL and the JDBC driver will make sure that the correct point in time is stored and retrieved back in any case, which is a great plus.

With these suggestions you don’t need to configure a specific time zone for your MySQL connection (and if someone configures one, no harm is done). You will need to convert dates and times for input and output for users in the USA, Singapore and elsewhere. This affects your interface alone, not your model. And it may entail changes to your existing code base if it is coded differently.

Link: Related question: Java Best Practice for Date Manipulation/Storage for Geographically Diverse Users

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161