"Строки занимают много места" - это аргумент мало значимый в данном контексте. Строки могут занимать даже меньше, например число в Oracle всегда занимает 19 байт, даже если вы укажете допустимый диапазон 1..10, а строка CREATED - всего 7 байт.
Во-вторых, если предполагается только добавлять статусы, то никакого рефакторинга/миграции БД не потребуется.
В-третьих читать текстовые коды в сырых данных приятнее, чем запоминать числовые коды.
Поэтому AttributeConverter советую использовать только там, где это действительно необходимо - частые изменения статусов в кодовой базе.
Для меня, моих коллег, которые тоже работают в моей доменной области (финтех) - это именно дата, и хранится как дата. Дата документа, контракта, ордера, соглашения и т.д. это LocalDate. И в базе он хранится соответствующим образом. По этим полям сортируется по времени, фильтруется по периодам, форматируется и т.д., все что обычно делается с датами. Все эти операции были бы невозможны, если делать, как вы предлагаете.
Есть ещё даты, таймстемпы с таймзоной - это логи, транзакции, события, которые могут происходить в разных регионах, и которые надо фиксировать соответствующим образом.
То, о чем вы говорите, это ваше воображение, которое не относится к первоначальной теме обсуждения, и вообще к айти.
Есть кончено, случаи, когда даты - не даты, например год рождения человека, который надо хранить. Но это другая тема.
...дата с таймзоной и дата без таймзоны, не подходящие типы...
Что за бред? Дата выдачи это - ДАТА в григорианском исчислении. Без таймзоны. Для хранения обычно используется LocalDate. Вы начинаете юлить, вместо того, чтобы использовать реальные аргументы.
...явно конвертировать в целевую таймзону...
...Перевод даты в offset это операция которую нельзя проводить...
Противоречие сами себе. Если нет таймзоны в дате, то и конвертировать нечего!
Ещё раз повторюсь: используйте LocalDate там, где не нужна зона и OffsetDate там, где нужна. Требования зависят от доменной области.
Почитайте подробнее или послушайте подкасты про то, как работать с типами дата/время, там можно в течении нескольких часов обсуждать нюансы и особенности. И на самом деле с точки зрения дат это не совсем просто число.
В каких именно?
Кто плотно работает с датами, тот сразу выдаст примеры. Дата выдачи паспорта, например. Если вы ее переведёте в offset, то в разных регионах может быть разная дата, а юридически дата должна быть одна и та же.
Никогда не сталкивался с описанными вами проблемами связанными с LocalDate/LocalDateTime, хотя часто работаю с ними, базы умеют работать с такими типами данных. Ещё есть ISO-8601, как уже указали. Важно понимать, что такое LocalDate и OffsetDate, для чего они предназначены и когда надо использовать один тип, а когда другой. В некоторых случаях категорически нельзя LocalDate заменить на OffsetDate или конвертировать в конкретную зону, как вы рекомендуете всегда делать.
Реализация GeneralLogMessages ну совсем уж кустарная и неправильная. Функция getFormatted принимает какие то разные параметры, хрен сразу пойми какие, не залезая в реализацию. Зачем там вообще enum, если используется только функционал формирования сообщения. Можно просто utils класс со статическими методами типа String buildNotFoundError(String resourceName, String path) и т.д.
"Строки занимают много места" - это аргумент мало значимый в данном контексте. Строки могут занимать даже меньше, например число в Oracle всегда занимает 19 байт, даже если вы укажете допустимый диапазон 1..10, а строка CREATED - всего 7 байт.
Во-вторых, если предполагается только добавлять статусы, то никакого рефакторинга/миграции БД не потребуется.
В-третьих читать текстовые коды в сырых данных приятнее, чем запоминать числовые коды.
Поэтому AttributeConverter советую использовать только там, где это действительно необходимо - частые изменения статусов в кодовой базе.
Не понимаю, что вы хотите сказать.
Для меня, моих коллег, которые тоже работают в моей доменной области (финтех) - это именно дата, и хранится как дата. Дата документа, контракта, ордера, соглашения и т.д. это LocalDate. И в базе он хранится соответствующим образом. По этим полям сортируется по времени, фильтруется по периодам, форматируется и т.д., все что обычно делается с датами. Все эти операции были бы невозможны, если делать, как вы предлагаете.
Есть ещё даты, таймстемпы с таймзоной - это логи, транзакции, события, которые могут происходить в разных регионах, и которые надо фиксировать соответствующим образом.
То, о чем вы говорите, это ваше воображение, которое не относится к первоначальной теме обсуждения, и вообще к айти.
Есть кончено, случаи, когда даты - не даты, например год рождения человека, который надо хранить. Но это другая тема.
Что за бред? Дата выдачи это - ДАТА в григорианском исчислении. Без таймзоны. Для хранения обычно используется LocalDate. Вы начинаете юлить, вместо того, чтобы использовать реальные аргументы.
Противоречие сами себе. Если нет таймзоны в дате, то и конвертировать нечего!
Ещё раз повторюсь: используйте LocalDate там, где не нужна зона и OffsetDate там, где нужна. Требования зависят от доменной области.
Вот, например, в подлодке обсуждали "Дата и время" выпуск называется https://music.yandex.ru/album/7570122/track/123897310?activeTab=track-list&ysclid=m5i7akp8im824672124
Там узнаете, что время может прыгать, ускоряться, замедляться, изменяться и т.д.
Почитайте подробнее или послушайте подкасты про то, как работать с типами дата/время, там можно в течении нескольких часов обсуждать нюансы и особенности. И на самом деле с точки зрения дат это не совсем просто число.
Кто плотно работает с датами, тот сразу выдаст примеры. Дата выдачи паспорта, например. Если вы ее переведёте в offset, то в разных регионах может быть разная дата, а юридически дата должна быть одна и та же.
Никогда не сталкивался с описанными вами проблемами связанными с LocalDate/LocalDateTime, хотя часто работаю с ними, базы умеют работать с такими типами данных. Ещё есть ISO-8601, как уже указали. Важно понимать, что такое LocalDate и OffsetDate, для чего они предназначены и когда надо использовать один тип, а когда другой. В некоторых случаях категорически нельзя LocalDate заменить на OffsetDate или конвертировать в конкретную зону, как вы рекомендуете всегда делать.
Реализация
GeneralLogMessagesну совсем уж кустарная и неправильная. Функция getFormatted принимает какие то разные параметры, хрен сразу пойми какие, не залезая в реализацию. Зачем там вообще enum, если используется только функционал формирования сообщения. Можно просто utils класс со статическими методами типа String buildNotFoundError(String resourceName, String path) и т.д.