Michael Simons, in my opinion, your fix makes things worse. With Calendar-as-a-Date (or plain Date), foobar.getRefDate().getTime().toString() should return 00:00:00 in the users timezone. Nearly all JDBC drivers do this. Your test case's entity returns the following refDate toString on most JDBC drivers, both before and after HHH-8517 is applied.

Tue Oct 22 00:00:00 EDT 2013

Obviously w/ your fix, an hour can be there depending on the offset. Like Steve said, what we were shooting for really is the expected behavior.

Brett, i thank for still looking into this.

If the timezone and the time components are so irrelevant, than please explain to my, why this fails:

@Test
	public void update() throws SQLException {
		this.entityManager.getTransaction().begin();
		Foobar foobar = new Foobar();
		Calendar hlp = Calendar.getInstance();
		// So this is now 2013-10-15 at Midnight CEST…
		hlp.set(2013, 10-1, 15, 0, 0, 0);
		foobar.setRefDate(hlp);
		foobar.setTakenOn(Calendar.getInstance());
		this.entityManager.persist(foobar);		
		this.entityManager.getTransaction().commit();
		final int id = foobar.getId();

		final DateFormat sf = new SimpleDateFormat("yyyy-MM-dd");
		
		Session session = entityManager.unwrap(Session.class);
		session.doWork(new Work() {			
			@Override
			public void execute(Connection connection) throws SQLException {
				ResultSet rs = connection.createStatement().executeQuery("Select ref_date from foobars where id = " + id);
				rs.next();
				Date date = rs.getDate(1);
				Assert.assertEquals("2013-10-15", sf.format(date));
				System.out.println(date);				
			}
		});		
	}

This only works if i set the calendar to hlp.set(2013, 10-1, 15, 2, 0, 0), otherwise the date ends up as 2013-10-14 in the database.

mysql> select * from foobars;
+----+------------+---------------------+
| id | ref_date   | taken_on            |
+----+------------+---------------------+
|  1 | 2013-10-15 | 2013-10-15 05:29:21 |
| 12 | 2013-10-14 | 2013-10-23 05:49:32 |
| 13 | 2013-10-14 | 2013-10-23 05:52:06 |
| 14 | 2013-10-14 | 2013-10-23 05:52:39 |
+----+------------+---------------------+

So i don't think we're done here.

This way it's even more fun:

/**
	 * When the TZ and Time of a date column are not relevant, than explain to me,
	 * why the date ends up as 2013-10-14 in my database....
	 * 
	 * Starting with
	 * INSERT INTO foobars(id, ref_date, taken_on) values (2, '2013-10-15', '2013-10-15 05:29:21');
	 * 
	 * @throws SQLException
	 */
	@Test
	public void update() throws SQLException {
		final Session session = entityManager.unwrap(Session.class);
						
		final DateFormat sf = new SimpleDateFormat("yyyy-MM-dd");
		
		this.entityManager.getTransaction().begin();
		Foobar foobar = this.entityManager.find(Foobar.class, 2);
		// Update some column to force an update...
		foobar.setSomeOtherColumn("blah");				
		this.entityManager.getTransaction().commit();
				
		final int id = foobar.getId();
		session.doWork(new Work() {			
			@Override
			public void execute(Connection connection) throws SQLException {
				ResultSet rs = connection.createStatement().executeQuery("Select ref_date from foobars where id = " + id);
				rs.next();
				Date date = rs.getDate(1);
				Assert.assertEquals("2013-10-15", sf.format(date));
				System.out.println(date);				
			}
		});
	}

Works perfectly in Hibernate 4.2.5 and doesn't in 4.2.6. You cannot blame the user (or me in this case) for bringing any time into this test case.

Sorry, but your implementation just doesn't work out and i'd be more than happy to help.

Ok, we're conceding that this needs revisited, although I still don't think the solution you provided was 100%. I'm reverting HHH-8517 and releasing 4.2.7.SP1.

Thanks, Brett.

The idea behind my proposal is based on the assumption that at least the MySQL JDBC driver

• handles time correct
• but converts them into the user JVM timezone

So the only way to be save with 00:00:00 is in UTC, therefore stripping is done there. Than the resulting value is converted back to the JVM timezone.

Regarding your comment https://hibernate.atlassian.net/browse/HHH-8617?focusedCommentId=54459&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-54459 i wonder why the TimeZone is EDT at all, because i set the default to something else in my test. Probably you're referring to use my proposal in the Calendar type, i guess.

But anyway, yes, there must be an hour (or hour and 30 minutes offsets, depending on the weird zones out there), in different zones in all cases there is a transformation from server UTC to JVM timezone in accordance with the JDBC spec.

I got that you want Hibernate JPA act like the JDBC spec but i also think that this is part of the problem (please, no offense, just my opinion).

Anyway, thanks for the discussion and again for looking into this.