Date - это более простой класс, и он используется в основном по причинам обратной совместимости. Если вам нужно установить определенные даты или выполнить арифметические операции с датами, используйте Календарь. Календари также обрабатывают локализацию. Предыдущие функции манипулирования датой Date с тех пор устарели.

Лично я предпочитаю использовать время в миллисекундах как long (или Long, в зависимости от ситуации) или Calendar, когда есть выбор.

И дата, и календарь являются изменяемыми, что может вызывать проблемы при использовании любого из них в API.

Лучший способ для нового кода (если ваша политика допускает сторонний код) - использовать библиотеку времени Joda.

Оба, Date и Calendar, так много проблем с дизайном, что ни то, ни другое хорошие решения для нового кода.

• Date и Calendar на самом деле являются одним и тем же фундаментальным понятием (оба представляют момент времени и являются оболочкой для базового значения long).

• Можно возразить, что Calendar на самом деле даже более сломан, чем Date, поскольку, кажется, предлагает конкретные факты о таких вещах, как день недели и время суток, тогда как если вы измените его свойство timeZone, конкретный превращается в бланманже! По этой причине ни один из объектов не является полезным в качестве хранилища года-месяца-дня или времени-дня.

• Используйте Calendar только как калькулятор, который при наличии объектов Date и TimeZone будет выполнять вычисления за вас. Избегайте его использования для ввода свойств в приложении.

• Используйте SimpleDateFormat вместе с TimeZone и Date для создания отображаемых строк.

• Если вы любите приключения, используйте Joda-Time, хотя это излишне сложно, ИМХО и скоро в любом случае будет заменено API дат JSR-310.

• Я уже отвечал, что нетрудно развернуть свой собственный класс YearMonthDay, который использует Calendar под капотом для вычисления даты. За это предложение меня проголосовали против, но я все еще считаю его верным, потому что Joda-Time ( и JSR-310) действительно слишком сложны для большинства случаев использования.

Дата лучше всего подходит для хранения объекта даты. Это постоянный, сериализованный ...

Календарь лучше всего подходит для управления датами.

Примечание: мы также иногда отдаем предпочтение java.lang.Long вместо Date, потому что Date является изменяемым и, следовательно, небезопасным для потоков. В объекте Date используйте setTime () и getTime () для переключения между ними. Например, постоянная дата в приложении (примеры: ноль 1970/01/01 или аппликативный END_OF_TIME, который вы установили на 2099/12/31; они очень полезны для замены нулевых значений в качестве времени начала и времени окончания, особенно когда вы сохраняете их в базе данных, поскольку SQL так своеобразен с нулями).

tl;dr

посоветуйте текущую "передовую практику" в отношении Date и Calendar

лучше всегда отдавать предпочтение Calendar над Date

Полностью избегайте этих устаревших классов. Вместо этого используйте классы java.time.

• На мгновение в UTC используйте _ 5_
  (современный эквивалент Date)
• На мгновение в определенном часовом поясе используйте _ 7_
  (современный эквивалент GregorianCalendar)
• На мгновение в конкретном offset-from-UTC используйте _ 9_
  (нет эквивалента в устаревших классах)
• Для даты и времени (не момента) с неизвестным часовым поясом или смещением используйте _ 10_
  (нет эквивалента в устаревших классах)

Подробности

Ответ Ортомалы Локни прав, предлагая использовать современный java.time, а не утомительные старые устаревшие классы даты и времени (Date, Calendar и т. д. ). Но этот ответ предлагает неправильный класс как эквивалент (см. Мой комментарий к этому ответу).

Использование java.time

Классы java.time - это огромное улучшение по сравнению с унаследованными классами даты и времени, разница между днем ​​и ночью. Старые классы плохо спроектированы, запутаны и неудобны. По возможности следует избегать старых классов. Но когда вам нужно преобразовать в / из старого / нового, вы можете сделать это, вызвав новые методы add к старым классам.

Для получения дополнительных сведений о преобразовании см. мой ответ и отличную диаграмму к другому вопросу, Преобразовать java.util.Date в какой тип «java.time»?.

Поиск по переполнению стека дает сотни примеров вопросов и ответов по использованию java.time. Но вот краткий обзор.

Instant

Получите текущий момент с Instant. Класс Instant представляет момент на временной шкале. в UTC с разрешением наносекунды (до девяти (9) цифр десятичной дроби).

Instant instant = Instant.now();

ZonedDateTime

Чтобы увидеть этот тот же одновременный момент через призму настенных часов определенного региона время, примените часовой пояс (ZoneId < / a>), чтобы получить ZonedDateTime.

Часовой пояс

Укажите правильное название часового пояса в формате continent/region, например _ 21_, _ 22_ или Pacific/Auckland. Никогда не используйте аббревиатуру из 3–4 букв, например EST или IST, поскольку они не истинных часовых поясов, не стандартизированы и даже не уникальны (!).

ZoneId z = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = instant.atZone();

Компенсировать

Часовой пояс - это история региона изменений в его смещении от UTC. Но иногда вам дается только смещение без полной зоны. В этом случае используйте класс OffsetDateTime.

ZoneOffset offset = ZoneOffset.parse( "+05:30" );
OffsetDateTime odt = instant.atOffset( offset );

Использование часового пояса предпочтительнее простого смещения.

LocalDateTime

«Местный» в Local… классах означает любую местность, а не конкретную местность. Так что название может показаться нелогичным.

LocalDateTime, LocalDate и LocalTime намеренно не имеют информации о смещении или часовом поясе. Таким образом, они не представляют реальные моменты, они не точки на временной шкале. В случае сомнений или затруднений используйте ZonedDateTime, а не LocalDateTime. Найдите Stack Overflow для более подробного обсуждения.

Струны

Не объединяйте объекты даты и времени со строками, представляющими их значение. Вы можете проанализировать строку, чтобы получить объект даты и времени, и вы можете сгенерировать строку из объекта даты и времени. Но строка никогда не является самой датой и временем.

Узнайте о стандартных форматах ISO 8601, используемых по умолчанию в классах java.time.

О java.time

java.time framework встроена в Java 8 и новее. Эти классы заменяют неудобные старые устаревшие классы даты и времени, такие как _ 36_, _ 37_, & _ 38_.

Проект Joda-Time теперь в режим обслуживания, советует перейти на java.time классы.

Чтобы узнать больше, см. Руководство по Oracle . И поищите в Stack Overflow множество примеров и объяснений. Спецификация - JSR 310.

Использование драйвера JDBC, совместимого с JDBC 4.2 или новее, вы можете обмениваться объектами java.time непосредственно с вашей базой данных. Не нужны ни строки, ни классы java.sql. *.

Где взять классы java.time?

• Java SE 8, Java SE 9, and later
  • Built-in.
  • Часть стандартного Java API со встроенной реализацией.
  • В Java 9 добавлены некоторые незначительные функции и исправления.
• Java SE 6 and Java SE 7
  • Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • Later versions of Android bundle implementations of the java.time classes.
  • Для более ранних версий Android проект ThreeTenABP адаптируется к < em> ThreeTen-Backport (упомянутый выше). См. Как использовать ThreeTenABP….

Проект ThreeTen-Extra расширяет java.time дополнительными классами. Этот проект является испытательной площадкой для возможных будущих дополнений к java.time. Здесь вы можете найти несколько полезных классов, например _39 _, YearWeek, _ 41_ и подробнее.

Я обычно использую Date, если это возможно. Хотя он изменяемый, мутаторы на самом деле устарели. В конце концов, он в основном оборачивается длинным, который будет представлять дату / время. И наоборот, я бы использовал календари, если мне нужно было манипулировать значениями.

Вы можете думать об этом так: вы используете StringBuffer только тогда, когда вам нужны строки, которыми вы можете легко манипулировать, а затем преобразовывать их в строки с помощью метода toString (). Точно так же я использую Календарь только в том случае, если мне нужно управлять временными данными.

Для наилучшей практики я стараюсь как можно чаще использовать неизменяемые объекты вне модели предметной области. Это значительно снижает вероятность каких-либо побочных эффектов и выполняется за вас компилятором, а не тестом JUnit. Вы используете этот метод, создавая в своем классе закрытые final поля.

И возвращаясь к аналогии с StringBuffer. Вот код, который показывает вам, как конвертировать между календарем и датой.

String s = "someString"; // immutable string
StringBuffer buf = new StringBuffer(s); // mutable "string" via StringBuffer
buf.append("x");
assertEquals("someStringx", buf.toString()); // convert to immutable String

// immutable date with hard coded format.  If you are hard
// coding the format, best practice is to hard code the locale
// of the format string, otherwise people in some parts of Europe
// are going to be mad at you.
Date date =     new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH).parse("2001-01-02");

// Convert Date to a Calendar
Calendar cal = Calendar.getInstance();
cal.setTime(date);

// mutate the value
cal.add(Calendar.YEAR, 1);

// convert back to Date
Date newDate = cal.getTime();

// 
assertEquals(new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH).parse("2002-01-02"), newDate);

Dates следует использовать как неизменяемые моменты времени; Calendar являются изменяемыми, и их можно передавать и изменять, если вам нужно сотрудничать с другими классами, чтобы придумать окончательную дату. Считайте их аналогами String и StringBuilder, и вы поймете, как я считаю их следует использовать.

(И да, я знаю, что Date на самом деле не является технически неизменным, но намерение состоит в том, что он не должен быть изменяемым, и если ничто не вызывает устаревшие методы, то это так.)

В Java 8 появился новый пакет java.time следует использовать.

Объекты неизменяемы, учитываются часовые пояса и переход на летнее время.

Вы можете создать объект ZonedDateTime из старый объект java.util.Date вроде этого:

    Date date = new Date();
    ZonedDateTime zonedDateTime = date.toInstant().atZone(ZoneId.systemDefault());

Я всегда выступаю за Joda-time. Вот почему.

1. API единообразен и интуитивно понятен. В отличие от API java.util.Date/Calendar
2. он не страдает от проблем с потоками, в отличие от java.text.SimpleDateFormat и т. д. (я видел множество клиентских проблем, связанных с непониманием того, что стандартное форматирование даты / времени не является потокобезопасным)
3. это основа новых API даты и времени Java (JSR310, запланированных для Java 8. Итак, вы будете использовать API, которые станут основными API Java.

РЕДАКТИРОВАТЬ: классы даты / времени Java, представленные в Java 8, теперь являются предпочтительным решением, если вы можете перейти на Java 8

Немного поздно на вечеринке, но в Java есть новый API даты и времени в JDK 8. Возможно, вы захотите обновить свою версию JDK и принять стандарт. Больше никаких беспорядочных дат / календаря, никаких сторонних банок.

Дата должна быть переработана. Вместо длинного целого числа он должен содержать год, месяц, дату, час, минуту, секунду как отдельные поля. Было бы даже хорошо сохранить календарь и часовой пояс, с которым связана эта дата.

В нашем естественном разговоре, если назначить встречу 1 ноября 2013 года в 13:00 по нью-йоркскому времени, это DateTime. Это НЕ Календарь. Таким образом, мы должны иметь возможность разговаривать подобным образом и на Java.

Когда Date хранится как длинное целое число (миллисекунды с 1 января 1970 года или что-то в этом роде), вычисление текущей даты зависит от календаря. В разных календарях указывается разная дата. Это с точки зрения определения абсолютного времени (например, 1 триллион секунд после Большого взрыва). Но часто нам также нужен удобный способ общения, например, объект, инкапсулирующий год, месяц и т. Д.

Интересно, есть ли в Java новые достижения для согласования этих двух целей. Возможно, мои знания Java слишком стары.

Кстати, «дата» обычно помечается как «устаревшая / устаревшая» (я не знаю точно почему) - что-то об этом написано там Java: почему конструктор Date устарел и что мне использовать вместо него?

Похоже, проблема только в конструкторе - через new Date (int year, int month, int day), рекомендуемый способ - через Calendar и отдельно настраивать параметры. . (Calendar cal = Calendar.getInstance ();).

Я использую Calendar, когда мне нужны определенные операции над датами, такие как перемещение во времени, но Date я считаю полезным, когда вам нужно отформатировать дату для соответствия вашим потребностям, недавно я обнаружил, что Locale имеет множество полезных операций и методов. Я использую Locale прямо сейчас!