Considero que la respuesta aceptada actualmente es incorrecta. Aunque java.sql.Time implica que sus campos de fecha están configurados en 1970-1-1, esto no es cierto. Si utiliza la conversión
new java.sql.Time(new LocalTime(...).toDateTimeToday().getMillis())
entonces la representación millesecond interna del objeto java.sql.Time reflejará la fecha de hoy. Esto conduce a un comportamiento inesperado cuando se comparan los objetos java.sql.Time. Las comparaciones se realizan en el valor de milisegundos, y si las fechas subyacentes son diferentes, los campos de tiempo son irrelevantes para el resultado de comparación
Un método mejor es trabajar explícitamente con los campos de tiempo, utilizando el constructor obsoleto y los métodos en java.sql.Time:
LocalTime localTime = new LocalTime(1,0,0,0);
java.sql.Time sqlTime = new java.sql.Time(localTime.getHourOfDay(), localTime.getMinuteOfHour(), localTime.getSecondOfMinute())
del mismo modo, en la otra dirección
java.sql.Time sqlTime = new java.sql.Time(1,0,0);
LocalTime localTime = new LocalTime(sqlTime.getHours(), sqlTime.getMinues(), sqlTime.getSeconds());
Utilizando métodos obsoletos es una mala práctica. – pgerstoft
Claro que sí, pero tienes que saber cuándo romper las reglas. Estos métodos en desuso son la manera más simple y más eficiente de lograr el objetivo, y no hay planes para eliminarlos de Java en el futuro previsible. Francamente, Sun nunca debería haberlos desaprobado; el horrible desastre que los reemplaza es la razón completa para pasar a la implementación más limpia, como JodaTime. –