То, как вы используете, прекрасно.Однако цель неясна.Почему вы хотите, чтобы c
было равно d
?
Кроме того, нет способа, чтобы d.toString() == "09:00:00"
- Date
всегда имела, ну, в том числе, дату.
Более важно, однако, то, что Date
не имеет информации о часовом поясе (хорошо, она имела обыкновение иметь, но вам не рекомендуется касаться этой части Date
), поэтому вы не можете отличить 09:00 UTC
от 10:00 BST
-то есть, если вы не укажете часовой пояс.Вы можете получить часовой пояс из Calendar c
, и это как бы объясняет, что вам нужно сделать:
- Создать
Calendar
из вашей даты - Скопировать часовой пояс из календаря, который выуже используйте
- Сравните поля
Calendar
, которые вас интересуют.Я полагаю, это будет час, минута, секунда и, возможно, миллисекунда.
Обновление: теперь, когда вы упомянули, что на самом деле java.sql.Time
, я волнуюсь,Проблема в том, что
- SQL-серверы обычно хранят время в виде структуры, содержащей часы, минуты, секунды и т. Д. То есть существует подразумеваемый часовой пояс (часовой пояс SQL Server)
java.sql.Time
хранит время в миллисекундах с момента «нулевой эпохи» 1 января 1970 года. Часть даты обычно вырезается до 1 января 1970 года - но этот класс не содержит информацию о часовом поясе.(Ну, опять же, вроде как, но не рекомендуется.) Calendar
имеет явно установленный часовой пояс
На практике это означает, что время отСервер преобразуется в миллисекунды с использованием системного часового пояса по умолчанию , затем вы читаете это значение и сравниваете его с Calendar
с его собственным часовым поясом.
Если это звучит запутанно и хрупко, это потому, чтоявляется.Таким образом, в основном у вас есть три часовых пояса:
- SQL Server TZ
- JVM по умолчанию TZ
- Календарь TZ
Все три должны бытьтак же, чтобы любое сравнение имело смысл.