I am using jodatime for datetime. When I persist the date in mysql it stores 2015-09-04 10:30:18 instead of 2015-09-04 14:30:18. My timezone is GMT+4 or UAE. Do you know how to change the timezone? I try to put GMT+4 but it does not work. I run this line on mysql

select now()

and it gives me the correct date and time.

Entity class below:

 @Type(type="org.jadira.usertype.dateandtime.joda.PersistentDateTime", parameters = { @Parameter(name = "databaseZone", value = "UTC"), @Parameter(name = "javaZone", value = "jvm")})
@Column(name = "CURRENT_DATE")
@Basic(fetch = FetchType.EAGER)
@XmlElement
DateTime currentDate;

The problem is only when it saves the datetime in mysql. If I have to retrieve the date from mysql to do some calculation, the date is correct that it will be 2015-09-04 14:30:18. But when it will store , it is 2015-09-04 10:30:18.
Glad if you can help to sort this out.
Thanks

Dani AI

Generated

Short diagnosis and cause (concise)
As and hinted, this is the persistence layer doing exactly what it’s configured to do: the Joda/Hibernate/Jadira mapping normalizes the instant to the database zone when writing and converts it back to the JVM zone when reading. That makes the row in the database appear 4 hours earlier if the database-side zone is UTC while your JVM is GMT+4. See the Jadira type docs for how the type and its zone parameters behave. (Jadira PersistentDateTime javadoc)

Recommended option (best practice)
Keep storing instants in UTC and do timezone conversion at display/logic time. This avoids DST and multi-server headaches and is the common practice for distributed systems. With Joda you can convert the instant for presentation, for example:

DateTime utc = originalDateTime.withZone(DateTimeZone.forID("UTC"));
DateTime dubai = utc.withZone(DateTimeZone.forID("Asia/Dubai"));

Use a canonical zone id like "Asia/Dubai" (not ambiguous abbreviations). (Joda‑Time zones) Connector/J and MySQL also document the “preserve instants / session‑zone” behavior and why normalizing to UTC is usually simpler. (Connector/J: preserving instants)

If you need wall‑clock values in the DB
Options if you absolutely must have the DB cell show local wall‑clock time:

  • Use DATETIME (no zone conversion) instead of TIMESTAMP (TIMESTAMP is subject to session conversions).
  • Change the persistence/connection configuration so the DB zone matches your desired wall‑clock (Jadira’s databaseZone or Hibernate’s jdbc time_zone, or Connector/J’s connectionTimeZone/serverTimezone in the JDBC URL). Be aware changing the session time_zone affects NOW(), CURTIME(), etc. (MySQL time zone manual).

Quick troubleshooting checklist

  1. Confirm column type (TIMESTAMP vs DATETIME).
  2. Check Hibernate/Jadira zone settings and hibernate.jdbc.time_zone. (Hibernate JdbcSettings)
  3. Check JDBC URL params (connectionTimeZone/serverTimezone) and the session zone (SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;).
  4. Log the bound SQL/timestamps to see the exact value sent to MySQL and adjust the above accordingly.

This explains why the DB row shows 10:30 while your app sees 14:30 and gives safe options depending on whether you prefer UTC storage or DB wall‑clock storage.

Recommended Answers

All 4 Replies

the timestamp is stored in UTC, which is normal, especially if the server is running on Unix.
It's up to you to do the conversion if needed.

Do you know how to do this conversion?

@Parameter(name = "databaseZone", value = "UTC")

Did you try to change this? Jadira defaults to using UTC in the database, and the JVM zone in the application.

I need to use timezone GMT+4 or UAE. I try to input GMT+4... and it's not correct!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.