16. Колонки в базе данных, в которых нужно хранить только дату, имеют тип date, в Котлине - LocalDate
Тут всё просто: зачем хранить в базе данных дату + время, если нам нужна только дата.
Пример плохого кода - хранить дату рождения формате дата + время:
val birthDate = Instant.parse("2016-01-06T15:22:53.403Z")
Хороший код - храним только дату:
val birthDate = LocalDate.parse("2016-01-06")
Хороший код намного упростит нам поиск по таблицам в базе данных с учётом даты рождения. Плохой код - заставит нас костылить для того, чтобы обойти тот факт, что в базе данных лежит не только дата, но и время. Ведь, с точки зрения базы данных (и она права), "2016-01-06T15:22:53.403Z" не может быть равно "2016-01-06".
17. Колонки в базе данных, в которых нужно хранить дату и время, имеют тип timestamptz, в Котлине - Instant (или другой, способный хранить метку временной зоны)
Это правило нужно не просто соблюдать на уровне приложения и базы данных, но и требовать его соблюдения от фронтенда и приложений, от которых ваше приложение получает данные.
Что будет, если его не соблюдать? У вас "поедут" временные зоны. Например для Москвы, в одних случаях у вас будет сохраняться время как UTC, в других - как UTC+3. В одном месте дата будет сегодняшним днём "2016-01-06T00:00:00.000Z" в другом - вчерашним "2016-01-05T21:00:00.000Z". В тестах, которые запускаются у вас локально будет одно время, в тестах в пайплайне - другое. Если вместо выравнивания типов данных, вы начнёте в коде костылить (прибавлять и отнимать часы, чтобы выравнять время), то это какое-то время будет работать только на вашем ноутбуке. В другом часовом поясе это работать не будет.
Поймать такой "плавающий" баг бывает непросто. Понять, как исправить - ещё сложнее. Поэтому всегда и везде нужно использовать однаковый тип данных, способный хранить и передавать метку временной зоны.
Альтернатива этому правилу - везде и всегда использовать тип данных без метки временной зоны. Но это уже совсем другая история.