For a very specific moment of time (daylight saving changes moment), Ebean returns a different Date after writing it down to a database and then reading it back in.

I created a public repository with a tiny application nicely reproducing this bug: https://github.com/sander24/ebean-daylight-saving-issue . Based on your kickstart application

"git clone", "mvn test", you'll see what's it about.

Validated that this bug is present with both MySQl and H2 as the database provider, so it is quite probable that source for this is somewhere inside EBeans.

For quick reference, here's the code of interest from my bug-reproducing mini-app:

public void test() {
// For it to fail, the time has to match the time at which the daylight saving changes
// are applied in that time zone. Therefore specify it explicitly.
TimeZone.setDefault(TimeZone.getTimeZone("EET"));

// Run the code and see how there is a 3600 second change
Date daylightSavingDate = new Date(1351382400000l);
// On a second run comment in the following date and see
// how there is a 0 second change
//daylightSavingDate = new Date(1361382400000l);

BasicEntity e = new BasicEntity();
e.setMyTimestamp(daylightSavingDate);

Ebean.save(e);
Assert.assertNotNull(e.getId());

// Reload the entity from database
BasicEntity e2 = Ebean.find(BasicEntity.class, e.getId());

System.out.println("The date I created " + daylightSavingDate);
System.out.println(" --- the date i put in : " + e.getMyTimestamp());
System.out.println(" as millis : " + e.getMyTimestamp().getTime());
System.out.println(" --- the date i get back : " + e2.getMyTimestamp());
System.out.println(" as millis : " + e2.getMyTimestamp().getTime());
System.out.println("The difference is " + (e2.getMyTimestamp().getTime() - e.getMyTimestamp().getTime())/1000 + " seconds");

}

OUTPUT:

The date I created Sun Oct 28 03:00:00 EEST 2012
--- the date i put in : Sun Oct 28 03:00:00 EEST 2012
as millis : 1351382400000
--- the date i get back : Sun Oct 28 03:00:00 EET 2012
as millis : 1351386000000

It is somewhat probable that this stuff comes from the String parsing methods of JDK that you are relying on.. anyhow, I think this behaviour is so highly undesired that we are experiencing here.. if the problem is indeed in JDK, a workaround of using a custom, improved method for parsing dates could/should probably be used...?

I know this happens quite rarely, but this leaves a very bad taste in my mouth, and should therefore be considered at least of medium priority. For example, our application run to this in production environment when validating data integrity. Of course, the integrity checks began failing once object's attribute values had been changed after writing/reloading the object to the database. Bad :(((

Thank you if possible to have a look at this :)