LINUX.ORG.RU

Жабаприколы

 ,


1

2
Calendar cal = GregorianCalendar.getInstance();
Date dt; //from somewhere
...
log(dt.getClass().getName()+" / "+cal.getTime().getClass().getName());
log(dt.getTime()+" / "+cal.getTime().getTime());
log("Equals:"+dt.equals(cal.getTime()));
java.sql.Timestamp / java.util.Date
1525107600000 / 1525107600000
Equals:false

Понаделали дат, где как хочу, так и equals. Тупо царское сравнивание по long рулит.

Ответ на: комментарий от crutch_master

Мы говорим о времени в информатике. А оно синхронизируется с атомных часов, где секунда - это целое число распадов.

Сейчас я тоже убью твою веру в человечество. Сказанное тобой не верно :D Секунды атомных часов не равны секундам Unix/Linux. Ядро Linux, например, понемногу подгоняет длину секунд, чтобы избежать високосных секунд. Високосные дни есть, переводы часов на зимнее/летнее время есть, а високосных секунд в Linux — нет. Они компенсируются несоответствием Linux-секунд физическим :)

KRoN73 ★★★★★
()
Ответ на: комментарий от crutch_master

Семантика чего? Календарный день везде будет 1000*60*60*24 мс.

Даже без учёта високосных секунд, календарный день бывает не только 24 часа, но и 23 часа и 25 часов :)

KRoN73 ★★★★★
()
Ответ на: комментарий от ma1uta

Ты даже не осилил перейти по ссылке и увидеть, что там никаких календарей нет...
If the field is a ChronoUnit then the addition is implemented here. The supported fields behave as follows:
...
DAYS - Returns an Instant with the specified number of days added. This is equivalent to plusSeconds(long) with the amount multiplied by 86,400 (24 hours).

День - это календарная абстракция. Что ты его сюда припёр, если это long с методами, а не календарь?

И как ты вернёшь абстрактный «месяц» в одном long-е?

Я его и не собираюсь возвращать в лонге. Потому что месяц - это календарная величина и он может быть от 28 до 31 дня +- секунда или еще какие-нибудь корректировки. Но когда он станет датой, а не интервалом, то будет лонгом, а ни чем-то другим.

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от KRoN73

Даже без учёта високосных секунд, календарный день бывает не только 24 часа, но и 23 часа и 25 часов :)

И 48, если дедлайн.

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Они компенсируются несоответствием Linux-секунд физическим :)

Ой вей, ну и костыль. Хотя есть в этом плюс. День всегда равен 24*60*60 сек.

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Я на эти грабли в начале Java-картеры наступил со сравнением Integer по ==. При чём особенно болезненное наступление было от того, что до 127 оно работает, а выше — уже нет :D

Ну == для объектов и не должно было работать, на это можно было напороться при первом сравнивании строк в самом начале освоения явы.

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от anonymous

А какой смысл складывать две даты(а не дату и интервал, например)?

madcore ★★★★★
()
Ответ на: комментарий от anonymous

Лонг можно умножить на 2, например. Какой смысл имеет умножение на 2 количества секунд от 1970? Никакого. Именно потому лонг и должен быть скрыт.

Показание электосчётчика тоже нет смысла умножать на 2. Значит его надо скрыть и запилить целый класс, вместо одного инта. А с id вообще нет смысла делать любые арифметические действия.

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

День всегда равен 24*60*60 сек

Как я выше замечал, во многих странах (и в России до некоторых времён) один день бывает 23*60*60 сек, а один — 25*60*60 сек :)

KRoN73 ★★★★★
()
Ответ на: комментарий от crutch_master

Ну == для объектов и не должно было работать

Для Integer «==» работает корректно для чисел от -128 до 127 :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Как я выше замечал, во многих странах (и в России до некоторых времён) один день бывает 23*60*60 сек, а один — 25*60*60 сек :)

Я думал ты угораешь просто.

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от crutch_master

Я думал ты угораешь просто.

Нет, перевод часов на летнее/зимнее время же :) Я на эти грабли в своей практике наступал уже где-то (хотя детали уже не помню).

KRoN73 ★★★★★
()
Ответ на: комментарий от crutch_master

Для этого в разных языках есть отдельные типы для момента времени и длительности. Добавить момент и длительность можно, добавить две длительности можно. Моменты нельзя добавить, но можно отнять и получить длительность. В них встроены юниты измерения в тип. А ты будешь множить и делить лонги, пока ваше видение с коллегами не разойдется где должны быть секунды, а реально миллисекунды. Или добавишь момент к моменту и ещё напишешь херовый тест, который это не поймает.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Если так подходить, то вообще все переменные надо в отдельные типы запаковать: «координата пиксела по горизонтали», «координата пиксела по вертикали», «расстояние между пикселами по вертикали», «расстояние между пикселами по горизонтали», «номер элемента в массиве», «длина подмассива», «длина подстроки», «номер символа в строке», «имя человека», «название города», «логин», «пароль», ...

Зато ничего не перепутаешь :-)

monk ★★★★★
()
Ответ на: комментарий от monk

Некоторые вещи можно. И даты и время - лучший пример. Точно так же если что-то парсится из текста, то лучше передавать разобраный и валидированый объект. Например не строку с телефоном, а прямо класс номера телефона. Его можно дальше не проверять на базовую валидность, так как невалидным его нельзя создать.

Если что-то просто число, то есть случаи когда для того чтобы ограничить операции с ним, все равно оборачивают в новый тип. Так читаемые, мол вот функция которая создаёт Foo, а вот, которая его получает. Если бы было просто int, то нужно было бы писать больше документации

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

И даты и время - лучший пример.

Семантика неоднозначна. Вот сколько должно быть «28 октября 2018 2:30 EUROPE/BERLIN» + «40 минут»? Или «25 марта 2018 1:30 EUROPE/BERLIN» + «40 минут»?

monk ★★★★★
()
Ответ на: комментарий от vertexua

Или добавишь момент к моменту и ещё напишешь херовый тест, который это не поймает.

А можно еще сложить цену с объёмом а потом разделить всё это на показание. И тест это тоже не поймает.

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от vertexua

Ну да. А что ты предлагаешь для каждой мелкой херни делать свои тип данных? У меня кварплата тогда будет считаться больше месяца.

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от vertexua

В чем проблема?

В том, что описанию «28 октября 2018 2:30 EUROPE/BERLIN» соответствует два момента времени (до и после перевода времени). Во втором случае через 40 минут будет «25 марта 2018 3:10 EUROPE/BERLIN» опять же из-за перевода.

И если второй случай хотя бы однозначен (хоть и неожиданный), то для «28 октября 2018 2:30 EUROPE/BERLIN» + «1 день» можно возвращать как «29 октября 2018 2:30 EUROPE/BERLIN» (то же время следующих суток), так и «29 октября 2018 3:30 EUROPE/BERLIN» (через 24 часа). Какой вариант считать верным?

monk ★★★★★
()
Ответ на: комментарий от crutch_master

для каждой мелкой херни делать свои тип данных? У меня кварплата тогда будет считаться больше месяца

???

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

monk ★★★★★
()
Ответ на: комментарий от monk

Время работы программы от типов данных практически не зависит (при правильной реализации не зависит совсем).

Ну, может и нет, если нормально всё сделать. Нахрена это надо только, кастить все эти велотипы туда-сюда и ловить эксепшены. Других проблем как будто мало.

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от crutch_master

Ты серьезно не знаешь что в куче языков типы вытираются в примитивы и служат только для ограничений операций?

vertexua ★★★★★
()
Ответ на: комментарий от monk

Отличный вопрос, я думаю его продумали в дизайне многих библиотек. Но если ты со мной споришь, то ты или как-то защищаешь юзание long для даты, как наркоман ТС, или нечего спорить, ведь я с тобой согласен. Проблемы есть и они могут быть решены типами

vertexua ★★★★★
()
Ответ на: комментарий от monk

Кстати, там вроде в таймзоне есть маркер часов. Тоесть сначала оно а Берлине, а потом немного в другом Берлине. Который через полгода вернётся назад в первый Берлин. Такая реализация приходит в голову. Отнимаете интервала тоже должно работать

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

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

В том-то и прикол, что разные библиотеки имеют по этим вопросам разное мнение. СУБД и MS Office игнорируют часовой пояс и позволяют записывать невозможное время (вплоть до 31 февраля в DBF). JS хранит время в секундах по UTC и вычисляет текущее по часовому поясу (иногда неправильно). С# для разницы DateTime не учитывает переход летнего/зимнего времени, то есть (end - start).TotalHours и (end.ToUniversalTime() - start.ToUniversalTime()).TotalHours вполне могут на единицу отличаться.

monk ★★★★★
()
Ответ на: комментарий от vertexua

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

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от anonymous

Героически решают проблемы, которых нет. Не писать код в говно бухим достаточно, чтобы не сделать их все.

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от aedeph_

Значение, возвращённое методом getTime(), является количеством миллисекунд, прошедших с 1 января 1970 года 00:00:00 по UTC. (c) ECMAScript

monk ★★★★★
()
Ответ на: комментарий от vertexua

Оно симметрично должно быть. Сделал equals для другого класса. Пойди в тот класс и сделай equals для этого.

Вот в примере топикстартера это нарушается. timestamp.equals(date) == false but date.equals(timestamp) == true. Кривой дизайн JDBC в общем. Там в комментах что-то про workaround-ы и написано. Походу пьяный индус перепутал типы, а потом пришлось втыкать костыли, т.к. другие пьяные индусы завязались на это поведение.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Жесть какая-то, нужно теперь зоопарк их этих типов в хешмапу в качестве ключа, посадить ТСа в камеру и не выпускать пока не отдебажит большую систему с этой хешмапой в тайном закоулке кода

vertexua ★★★★★
()
Ответ на: комментарий от aedeph_

Ок, а микросекунд?

Тогда структура с двумя полями будет

И как кодировать до 1970 года?

Отрицательными числами

monk ★★★★★
()
Ответ на: комментарий от aedeph_

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от drsm

Если их нет, то можно их сделать как и Uint32Array.

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от aedeph_

То есть ожидаемо long лососнул

Давай. Расскажи, в чём хранить 500 миллионов дат, кроме лонга, как потом делать выборки по ним и сколько это будет длиться.

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от theNamelessOne

Ну, как бы да, хоть это и обёртка над 64-битном флоатом с 53 значимыми битами.

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

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

ну и где ты этот бред вычитал? или сам придумал? ты же в курсе, что високосная секунда может как добавляться, так и отниматься, притом не периодически, а как земля повернётся? что же это за хитрый алгоритм такой, который «понемногу подгоняет длину секунд» к случайной величине?

в unix-time нет «60-й секунды» как раз из-за того, что високосную секунду невозможно предсказать с достаточной точностью и, следовательно, невозможно точно отвести под неё значение в равномерном счёте. поэтому в unix-time просто либо пропускают, либо дублируют последнюю секунду дня.

https://en.wikipedia.org/wiki/Unix_time

anonymous
()
Ответ на: комментарий от aedeph_

Ну что сразу ок. Расскажи, давай, как ты будешь хранить в базе какой-нибудь объект, или год-месяц-день, или что у вас там модно.

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.