Any reason why you removed this?

Request is that output Time should represent local time on January 1st 1970, but it input can be on any date, for example:

jshell> var t = new Time(System.currentTimeMillis())
t ==> 22:24:43

jshell> new Date(t.getTime())
$6 ==> Thu May 15 22:24:43 CEST 2025

This the reason why we have to treat it like any other java.util.Date subclass

jshell> var tt = T.millisToSqlTime(t.getTime())
tt ==> 22:24:43

This is now java.sql.Time instance on January 1st 1970

jshell> new Date(tt.getTime())
$11 ==> Thu Jan 01 22:24:43 CET 1970

I get that, it's just unfortunate that we would have to create copies every time we bind a java.sql.Time to a prepared statement even if the value already is correctly at the epoch date.

That is true. One possibility to prevent this is to return time if it is already at epoch date, and make new copy if not. Something like

		if ( value instanceof Time time ) {
			Date date = new Date( time.getTime() );
			if ( date.getYear() == 70 && date.getMonth() == 0 && date.getDate() == 1 ) {
				return time;
			}
		}

Alternatively java.util.Calendar can be used, but I guess that this is 'cheaper' to create java.util.Date instance than java.util.Calendar

		if ( value instanceof Time time ) {
			Calendar calendar = Calendar.getInstance();
			calendar.setTime( time );
			if ( calendar.get( Calendar.YEAR ) == 1970
				 && calendar.get( Calendar.MONTH ) == Calendar.JANUARY
				 && calendar.get( Calendar.DAY_OF_MONTH ) == 1 ) {
				return time;
			}
		}

Maybe I'm missing something, but java.util.Date#getTime() specifies

Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object.

So AFAIU, using the modulo trick that we have right now should work just fine. Please help me understand what I am missing. According so java docs the code should be correct.

getHours() is deprecated and the Java doc also explains that it returns the TZ dependent value.

That's correct, that (and all other getXXX methods, with exception of getTime) were deprecated starting from JDK 1.1. Additional reason why java.time classes should be used.

Anyway, I see that you are using Time.valueOf(LocalTIme) (seven out of eight times in hibernate-core), so here is one example ...

jshell> var newYork = Time.valueOf(LocalTime.of(23, 0))
newYork ==> 23:00:00

jshell> newYork.getTime()
$20 ==> 100800000

jshell> Time.valueOf(LocalTime.of(12, 0))
$21 ==> 12:00:00

jshell> $21.getTime()
$22 ==> 61200000

Anyway, I see that you are using Time.valueOf(LocalTIme) (seven out of eight times in hibernate-core), so here is one example ...

In fact, java.sql.Time#valueOf(java.time.LocalTime) will interpret the LocalTime as being a time in the time zone of the JVM, which is IMO natural given the way java.sql.Time#getTime() is specified. So to compute the milliseconds for that time since the epoch, it will have to add the time zone offset for the 1st January 1970, which is GMT-5, so it will have to add 18000000 milliseconds to get a GMT value.

I don't know where java.sql.Time#valueOf(java.time.LocalTime) is used in our code, but I agree that we have to be careful not to use that method if the LocalTime value comes from the database, because AFAIU that value would have no time zone association.

I don't know where java.sql.Time#valueOf(java.time.LocalTime) is used in our code, but I agree that we have to be careful not to use that method if the LocalTime value comes from the database, because AFAIU that value would have no time zone association.

org.hibernate.query.hql.internal.SemanticQueryBuilder#sqlTimeLiteralFrom
org.hibernate.type.descriptor.java.JdbcTimeJavaType#wrap
org.hibernate.type.descriptor.java.JdbcTimeJavaType#fromString
org.hibernate.type.descriptor.java.JdbcTimeJavaType#fromEncodedString
org.hibernate.type.descriptor.java.LocalTimeJavaType#unwrap
org.hibernate.type.descriptor.java.OffsetTimeJavaType#unwrap
`org.hibernate.type.descriptor.jdbc.TimeUtcAsJdbcTimeJdbcType#getBinder

Anyway as Yoggi Berra used to say, it's like déjà vu all over again, so I suggest that this PR be closed.

I don't want to discourage you on your quest to fix time zone related issues, but we have to be careful to fully understand real problems before doing anything.
I'm sure there is a bug hiding somewhere, but it would be best if we first start off with a real use case that fails.