Одному мне кажется, что проблемы с преобразованием форматов на стороне сервера к Java вообще никого отношения не имеют?

Читать доку по SQL серверу, как правильно преобразоывать строки в тип времени

Сильно напоминает "You might receive unexpected results in JDBC and SQLJ applications if you use date, time, and timestamp values that do not correspond to real dates and times." ( C ) какая-то документация

поскольку нифига не понятно, что же именно сохранено в базе (да и какая собственно база и дравера), думаю, что-то большее угадать по хрустальному шару крайне тяжело

если драйвер jConnect, то пальцем в небо можно попытаться "Set the connection option RETURN_DATE_TIME_AS_STRING to ON in order to get SQL Anywhere to always return DATE/TIME/TIMESTAMP values as strings. "
по крайне мере, проще будет тестить, что же именно приходит от сервера и что же именно хранится в базе

IMHO

Выличить удалось? Если да, то как?

sergnn...воспринимается как 23:29 31 декабря 1969 года...

JavaDocpublic class Time
extends Date

A thin wrapper around the java.util.Date class that allows the JDBC API to identify this as an SQL TIME value. The Time class adds formatting and parsing operations to support the JDBC escape syntax for time values.

The date components should be set to the "zero epoch" value of January 1, 1970 and should not be accessed .

А если:
SELECT CONVERT( time, '00:29:00', 14 )
?

Вообще, все больше кажется. что проблема с тайм-зоной (зимнее/летнее время). Но тогда "падеж падежей" у Вас должен быть на всех константах, не только на 0:29.

To define a time you need the time and the time zone. A time stamp is the time which passed since
January 1, 1970, 00:00:00 GMT. So a time stamp is well defined and should not be changed in anyway when its written to the database.
Otherwise you end up with that strange situation that time stamp 0 is not January 1, 1970, 00:00:00 GMT.

sergnnТам есть Cast.
CAST это кастование из одного типа в другой.

Кастовать строчки, без явного указания формата.... "гарантию может дать только страховой полис". Т.к., вообще то, используемый формат может зависит от настроект базы/клиента/соединения/страны (часового пояса)

sergnnВидимо придётся в базе храните в стрингах.
И преобразовывать в Time уже в приложении
мне года 4-и назад, ровно так и пришлось поступить
https://www.sql.ru/forum/1187891/jdbc-postgres-java-time-zoneddatetime?hl=timezone postgresql

обычно со строками только одна проблема - сортировка в базе, но для чисто времени: что time, что varchar - будет сортировать (и даже сравнивать) правильно. Т.ч., в общем-то и пофиг.

А с учетом, как через ж.... в Java сделаны типы с датой, возможно хранить в varchar это и хорошо (надежнее).