1

I have a datetime column in mysql database (colum is called creation_date), everytime im going to save the entity that has that column I fill that column like so (it is a LocalDateTime in my java class):

public static LocalDateTime argDate() {
    return LocalDateTime.now(ZoneId.of("America/Argentina/Buenos_Aires"));
}

So I need to make a calculation with that date, to check which records have certain conditions and one of those is if the time between the current date and that "creation_date" is equal or higher than 70 seconds, do something with that, so I would like to make sure I am working with only Argentina time to have accurate results and no mistakes, so this works:

long seconds = ChronoUnit.SECONDS.between(entity.getCreationDate(), argDate());

that method works, but I wanted to be 100% sure that I am working with Argentina date, so I tried this but started getting the error in the title:

long seconds = ChronoUnit.SECONDS.between(entity.getCreationDate().atZone(ZoneId.of("America/Argentina/Buenos_Aires")), argDate());

The thing is I have many questions right now, one is if the column type at Mysql will always give me back the datetime in Argentina time because since I am always saving it with that ZoneId, I would expect that to be that way...

And another one is how can I fix that error on the title? So I make sure I am working with Argentina time and the calculation of the seconds is good

So far I believe that my assumption that the Mysql datetime being in Argentina time is correct, because I decided to log some entries and this is the output:

LocalDateTime now = argDate();
log.info("database entity creation_date (arg): {}, now (arg): {}", entity.getCreationDate(), now);

Output:

database entity creation_date (arg): 2023-07-20T15:08:25, now (arg): 2023-07-20T15:09:24.013604344

But my fear is that maybe this is not true? And the timezone of the server of the database is argentina time luckyly? Or is it respecting the zoneId I gave it when saving it

Research:

According to this answer I should not worry about this scenario, since it is a datetime column it will respect the zoneId I gave it before saving it (Argentina), so when I retrieve this from database it will already be in Arg time, but still curious of how to fix the error on title

BugsOverflow
  • 386
  • 3
  • 19

1 Answers1

2

entity.getCreationDate().atZone(ZoneId.of("America/Argentina/Buenos_Aires")) returns a ZonedDateTime and hence the error because then you are trying to find a difference between a ZonedDateTime and a LocalDateTime. Change it to

long seconds = ChronoUnit.SECONDS.between(entity.getCreationDate(), argDate());

Since you are already storing LocalDateTime in your database, this will give you the difference between the two LocalDateTimes.

If you still want to use entity.getCreationDate().atZone(ZoneId.of("America/Argentina/Buenos_Aires")), you need to change the definition of argDate to

public static ZonedDateTime argDate() {
    return ZonedDateTime.now(ZoneId.of("America/Argentina/Buenos_Aires"));
}

so that you can find the difference between two ZonedDateTimes.

Arvind Kumar Avinash
  • 71,965
  • 6
  • 74
  • 110
  • Cool yes I was searching a bit, I should not worry because since im saving with the zoneId of argentina to the mysql databse, it is respecting this, but your proposal to change to ZonedDateTime is interesting, if I save to mysql database, it will still be valid for the datetime column? – BugsOverflow Jul 20 '23 at 18:45
  • 1
    *if I save to mysql database, it will still be valid for the datetime column?* - not without changing the column type in your DB . Please do check [this](https://stackoverflow.com/a/67752047/10819573) and [this](https://stackoverflow.com/a/67505173/10819573). – Arvind Kumar Avinash Jul 20 '23 at 18:48
  • Another suggested reading is [this](https://dev.mysql.com/blog-archive/support-for-date-time-types-in-connector-j-8-0/). Check here the section, **OffsetDateTime and ZonedDateTime support**. – Arvind Kumar Avinash Jul 20 '23 at 18:56