Дата Java по сравнению с календарем

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

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

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

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

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

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

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

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

Я всегда выступаю за Джода-тайм . И вот почему.

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

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

Оба, Дата и Календарь имеют так много проблем с дизайном, что ни одно из них не является хорошим решением для нового кода.

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

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

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

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

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

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

И возвращаясь к аналогии с 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);