Сталкивался ли тут кто-нибудь с проблемой округления микросекунд у Instant'а?

Поясню чуть подробнее: в базе данных хранятся инстанты (timestamp'ы в формате date & time), которые допускают 6 знаков после запятой. Например 2021-10-13T15:04:24.944921Z https://www.cockroachlabs.com/docs/stable/timestamp.html#syntax

Во время создания/обновления сущностей внутри транзакции хибер в начале кладёт сущность в кэш (перед тем как закоммитить), при этом аудит из spring data указывает дату создания сущности посредством некоторых махинаций вокругInstant#now(). По итогу приходит инстант с 9-ю знаками после запятой, например: 2021-10-13T07:14:47.791616921Z. Я не могу просто взять и вызвать Instant#truncatedTo с кастингом под микросекунды, всё потому, что данный метод не округляет к большему значению данный инстант, а вот при записи в базу он округляется. https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html#truncatedTo-java.time.temporal.TemporalUnit-

Есть ли элегантное решение данной проблемы?

P.S: важно отметить, что данная проблема актуальна только для получения сущности, ведь при создании возвращается новосозданная сущность с 9-ти значными микросекундами. Т.е конвертируется в дто. В базе все хранится в соответствии со стандартами.

А в чем конкретно проблема? Ну режит и режит, бог с ним. Там с кэш-ом hiber-а какие то проблемы?

Проблема с округлением. В базе хранится дейт не подрезанный, а с округлением. Пример: 2021-10-13T07:14:47.791616921Z -> 2021-10-13T07:14:47.791617Z

Нет, с кэшом все в норме. Я описал подробнее проблему, чтобы был ясен полный контекст. А вопрос связан исключительно с округлением инстанта.

какие негативные эффекты возникют из-за округления?

Из-за округления посредством чего именно?

от той, которую вы описывете

Я описываю пример с truncatedTo. Если речь про него - то там же и описано почему вариант не подходит. И в доках тоже. Он округляет вниз, не вверх.

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

Проблема неприятная из-за того, что на сущность завязываются внешние системы. Более того, важна унификация.

Если честно, и правда непонятно, в чём проблема. Instant поддерживает 9 знаков, база - 6 знаков. При сохранении происходит округление и при запросе возвращается округлённое значение. Если база не поддерживает наносекунды, никуда от этого не деться.

Никуда от этого не деться, но мне неясно почему проблематика непонятна. Т.е я к тому, что изначально аудитор по каким-то причинам не округляет. И в теории округление уже идёт на уровне базы у jpa.

Ну и пусть округляет, какая разница-то?

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

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

Я встречался максимум с тем, что тестовые данные с Instant.now(), загруженные в БД, теряют точность до миллисекунд, и чтобы спокойно делать assertEquals приходилось использовать truncatedTo

Самое забавное, что база (постгресс и все околоплодное) округляет до большего значения 😳

До микросекунд

Зависит от БД