Ароматизированный исходный код не скомпилирован в Android

LATE EDIT: Начиная с Java 8, вы не должны использовать ни java.util.Date, ни java.sql.Date, если можете вообще избежать этого, и вместо этого предпочитаете использовать пакет java.time (на основе Joda) а не что-либо другое. Если вы не на Java 8, вот исходный ответ:

java.sql.Date - когда вы вызываете методы / конструкторы библиотек, которые его используют (например, JDBC). Не иначе. Вы не хотите вводить зависимости к библиотекам баз данных для приложений / модулей, которые явно не имеют отношения к JDBC.

java.util.Date - при использовании библиотек, которые его используют. В противном случае, как можно меньше, по нескольким причинам:

• Это изменчиво, что означает, что вы должны сделать защитную копию этого файла каждый раз, когда вы передаете его или возвращаете его из метода.
• Он не очень хорошо справляется с датами, которые, как и ваши, действительно напоминают людям, считают классы обработки даты.
• Теперь, поскольку j.u.D не делает работу очень хорошо, были введены ужасные классы Calendar.
• Существуют лучшие альтернативы, такие как Joda Time API (который, в свою очередь, может быть изменен и ужасен для работы, и его следует избегать, если у вас нет выбора. может даже превратиться в Java 7 и стать новым официальным API обработки дат - быстрый поиск говорит, что он не будет).

Если вы чувствуете, что это слишком много, ввести новую зависимость, такую ​​как Joda, long s, не так уж плохо использовать для полей timestamp в объектах, хотя я сам обычно обертываю их в juD при их передаче, для безопасности типов и документации.