Reputation: 107
I have a table in my MySQL database that has a date column:
+-------------------+---------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+---------------+------+-----+---------+----------------+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| type | varchar(50) | NO | | NULL | |
| expiration | date | NO | | NULL | |
I'm using MySQL with JPA to save dates. I have a feature that the user can select a final date range and it will get all the dates.
Check out this code (with a bunch of SYSOs) to try to see whats going on...
@Override
protected DateTime nextReference(DateTime reference) {
System.out.println("Reference: " + reference.toString("dd-MM-YYYY"));
DateTime plus = reference.plusMonths(1);
System.out.println("One month from now: " + plus.toString("dd-MM-YYYY"));
DateTime result = plus.withDayOfMonth(reference.getDayOfMonth());
System.out.println("Final: " + result.toString("dd-MM-YYYY"));
return result;
}
This part, the result was fine:
Reference: 10-01-2017
One month from now: 10-02-2017
Final: 10-02-2017
Reference: 10-02-2017
One month from now: 10-03-2017
Final: 10-03-2017
Reference: 10-03-2017
One month from now: 10-04-2017
Final: 10-04-2017
Reference: 10-04-2017
One month from now: 10-05-2017
Final: 10-05-2017
Reference: 10-05-2017
One month from now: 10-06-2017
Final: 10-06-2017
Reference: 10-06-2017
One month from now: 10-07-2017
Final: 10-07-2017
Reference: 10-07-2017
One month from now: 10-08-2017
Final: 10-08-2017
Reference: 10-08-2017
One month from now: 10-09-2017
Final: 10-09-2017
Reference: 10-09-2017
One month from now: 10-10-2017
Final: 10-10-2017
Reference: 10-10-2017
One month from now: 10-11-2017
Final: 10-11-2017
Reference: 10-11-2017
One month from now: 10-12-2017
Final: 10-12-2017
Reference: 10-12-2017
One month from now: 10-01-2018
Final: 10-01-2018
Ok, now lets move to the save part:
@Transactional
private void saveTransactions(List<Transaction> transactions) {
for (Transaction t : transactions) {
System.out.println("Saving: " + t.getExpiration().toString("dd-MM-YYYY"));
Transaction saved = dao.save(t);
System.out.println("Saved: " + saved.getExpiration().toString("dd-MM-YYYY"));
}
}
As you can see, I put some lines to debug this also.... Before I continue with the output, check out the DAO:
public T save(T entity) {
entityManager.persist(entity);
return entity;
}
No big deal right... The output:
Saving: 10-02-2017
Saved: 10-02-2017
Saving: 10-03-2017
Saved: 10-03-2017
Saving: 10-04-2017
Saved: 10-04-2017
Saving: 10-05-2017
Saved: 10-05-2017
Saving: 10-06-2017
Saved: 10-06-2017
Saving: 10-07-2017
Saved: 10-07-2017
Saving: 10-08-2017
Saved: 10-08-2017
Saving: 10-09-2017
Saved: 10-09-2017
Saving: 10-10-2017
Saved: 10-10-2017
Saving: 10-11-2017
Saved: 10-11-2017
Saving: 10-12-2017
Saved: 10-12-2017
As you can see... It should be fine right? Everything on the 10th.
Before I continue again, check the model, and the converter:
//Attribute
@Convert(converter = JpaDateConverter.class)
private DateTime expiration;
//Converter
public class JpaDateConverter implements AttributeConverter<DateTime, Date> {
@Override
public Date convertToDatabaseColumn(DateTime objectValue) {
return objectValue == null ? null : new Date(objectValue.getMillis());
}
@Override
public DateTime convertToEntityAttribute(Date dataValue) {
return dataValue == null ? null : new DateTime(dataValue);
}
}
Now look at my database:
mysql> select expiration from tb_transaction where notes = 3 and year(expiration
) = 2017;
+------------+
| expiration |
+------------+
| 2017-01-10 |
| 2017-02-10 |
| 2017-03-09 |
| 2017-04-09 |
| 2017-05-09 |
| 2017-06-09 |
| 2017-07-09 |
| 2017-08-09 |
| 2017-09-09 |
| 2017-10-09 |
| 2017-11-10 |
| 2017-12-10 |
+------------+
12 rows in set (0.00 sec)
For some, wierd, mystic reason, some dates where saved on the 9ths instead of the 10th !!
No Warnings, no Errors on MySQL driver or nothing.
Please HELP guys!
EDIT Transaction Class:
@Entity
@Table(name = "tb_transaction")
public class Transaction implements Cloneable {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Enumerated(STRING)
private TransactionType type;
@Convert(converter = JpaDateConverter.class)
private DateTime expiration;
Upvotes: 3
Views: 6164
Reputation: 340230
Use JPA 2.2 for its support of java.time.
Use a date-only class in Java to work with date-only values in SQL.
LocalDate // Represent a date-only, without a time-of-day and without a time zone.
.now( // Get today's date…
ZoneId.of( "Africa/Tunis" ) // …as seen in the wall-clock time used by the people of a particular region.
) // Returns a `LocalDate` object.
.plusMonths( 1 ) // Returns another `LocalDate` object, per immutable objects pattern.
JPA 2.2 now supports the modern java.time classes. No need to use Joda-Time anymore.
Do not use java.sql.Date
. That class pretends to represent a date-only but actually has a time-of-day set to UTC because of the terrible design decision to inherit from java.util.Date
(which despite the name represents a date and a time-of-day and an offset of zero for UTC itself). These legacy classes are an awful wretched mess. Sun, Oracle, and the JCP community all gave up on theses classes years ago with the adoption of JSR 310, and so should you.
LocalDate
The LocalDate
class represents a date-only value without time-of-day and without time zone or offset-from-UTC.
A time zone is crucial in determining a date. For any given moment, the date varies around the globe by zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec.
If no time zone is specified, the JVM implicitly applies its current default time zone. That default may change at any moment during runtime(!), so your results may vary. Better to specify your desired/expected time zone explicitly as an argument. If critical, confirm the zone with your user.
Specify a proper time zone name in the format of Continent/Region
, such as America/Montreal
, Africa/Casablanca
, or Pacific/Auckland
. Never use the 2-4 letter abbreviation such as EST
or IST
as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" ) ;
LocalDate today = LocalDate.now( z ) ;
If you want to use the JVM’s current default time zone, ask for it and pass as an argument. If omitted, the code becomes ambiguous to read in that we do not know for certain if you intended to use the default or if you, like so many programmers, were unaware of the issue.
ZoneId z = ZoneId.systemDefault() ; // Get JVM’s current default time zone.
Or specify a date. You may set the month by a number, with sane numbering 1-12 for January-December.
LocalDate ld = LocalDate.of( 1986 , 2 , 23 ) ; // Years use sane direct numbering (1986 means year 1986). Months use sane numbering, 1-12 for January-December.
Or, better, use the Month
enum objects pre-defined, one for each month of the year. Tip: Use these Month
objects throughout your codebase rather than a mere integer number to make your code more self-documenting, ensure valid values, and provide type-safety. Ditto for Year
& YearMonth
.
LocalDate ld = LocalDate.of( 1986 , Month.FEBRUARY , 23 ) ;
Apparently you want to start with one date and get one month later as a date range.
LocalDate monthLater = ld.plusMonths( 1 ) ;
As of JDBC 4.2, your JDBC driver is required to support some of the key java.time classes such as LocalDate
.
Note the links below for ThreeTen-Extra. You may find the LocalDateRange
class there to be handy if you do much work with date ranges.
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date
, Calendar
, & SimpleDateFormat
.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.*
classes.
Where to obtain the java.time classes?
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval
, YearWeek
, YearQuarter
, and more.
Upvotes: 5
Reputation: 107
Thanks to @RickS, we solved this issue.
PS: I solved this a long time ago, and experienced this issue again 2 years later. lol
The solution is in the converter: JpaDateConverter, when you convert a DateTime Objetivo to java.sql.Date, according to the docs:
If the given milliseconds value contains time information, the driver will set the time components to the time in the default time zone (the time zone of the Java virtual machine running the application) that corresponds to zero GMT.
So to fix this I changed the server timezone:
dpkg-reconfigure tzdata
And in MySQL:
SET @@global.time_zone = '+00:00';
Upvotes: 3