Почему манипулирование датой в Java с миллисекундами?

Question

Недавно я столкнулся с проблемой вычисления количества дней из двух дат в Java (боюсь, без использования joda). Поиск в сети показывает, что большинство ответов на этот вопрос говорят, чтобы получить миллисекунды двух дней и преобразовать их в дни, которые я нашел ужасающими. Однако немногие демонстрируют другой подход: используйте временную переменную, чтобы подсчитать, сколько раз требуется добавить 1 день к первой дате, чтобы добраться до второй. Это оставляет преобразования в код, который делает это лучше всего: библиотека.

Почему так много людей выступают за первое?

В другом проекте я ранее сталкивался с многочисленными тонкими проблемами вычисления даты, включая часовые пояса, переход на летнее время и даже високосные годы, используя секунды для сравнения и вычисления дат. Все это исчезло, когда all код сравнения и вычисления был перезапущен для использования языковых библиотек. (Однако это было в PHP, где библиотеки структурированы совсем по-другому, чем в Java.) Поэтому я вполне неохотно использую эту «общую мудрость» в мире Java для сравнения дат.

Answer 1

Это может быть легко и эффективно, но определенно не то, что вы хотите внедрить в производство.

Например, в страховой отрасли этот способ расчета может привести к ошибке дня, когдаправильная граница, может привести к ошибке года, что приведет к неправильному расчету возраста и, возможно, к отказу от страхового возмещения :) (см. здесь для получения QED)

Я пришелчерез катастрофическую ситуацию, когда эти миллисекундные манипуляции использовались в Великобритании (где у них летнее время), и это был настоящий беспорядок.

Итак, чтобы ответить на ваш вопрос:

Почемутак много людей выступают за первое?

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

Answer 2

Я предлагаю как можно больше преобразований вашего часового пояса в графический интерфейс пользователя. Я предлагаю, чтобы все ваши серверы работали в GMT (или в другое фиксированное время). Это значительно упростит ваши вычисления, поскольку System.currentTimeMillis () находится во времени GMT. например чтобы получить день по Гринвичу просто

long day = System.currentTimeMillis() / 86400000;
long anotherDay = anotherMillis / 86400000;
long intervalInDays = day - anotherDay; 

Как утверждает @Ryan, вам необходимо понять последствия использования даты / времени напрямую.

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

Использование long - это намного быстрее, но для 90% приложений вам это не нужно, и вам лучше использовать высокоуровневую библиотеку. (Все равно оставил бы все серверы с согласованным часовым поясом и позволил бы графическому интерфейсу решить, как его отображать)

Вы должны взвесить цену ошибки и стоимость того, что вы недостаточно быстры.

Answer 3

Потому что это просто и эффективно.

Не ссылаясь на одну страницу Javadoc, я знаю все API, которые мне нужны для манипулирования датами описанным вами образом: java.util.Date#getTime() и базовая арифметика - вот и все .

Да, это низкий уровень, но стандартная библиотека дат в Java - это катастрофа.