Comments 11
Только сохранять надо не время UTC плюс часовой сдвиг, а время по UTC и часовой пояс (то есть Asia/Vladivostok, а не +10:00). Потому что если вы празднуете день рождения в 11 часов ночи, то вы будете праздновать в 11 часов ночи по Владивостоку даже если Владивосток решит, что у него теперь UTC+9.
Точное время рождения вы не ставите и вместо вас его ставит ваше устройство как 00:00
Вот здесь ещё ошибка, потому что сохранять надо было именно дату, без времени вообще, а не пытаться моделировать временной меткой, надеясь, что момент времени не уплывёт на другой день. Часовые пояса простираются от –12 до +14, так что при таком подходе по какому бы поясу вы бы не сохраняли — где-нибудь у вас будет «неправильная» дата рождения по местному времени.
Вы спутали два понятия:
1) момент рождения (хотя, разве это момент? интервал, скорее) в UTC, который, нужен только, если стоит задача, определить, кто из двух лиц старше,
2) запись в паспорте, которая инвариантна, т.е. при записи во всякие базы данных меняться не должна.
P.S. Вы еще скажите, что человек родившийся 29 февраля високосного года стареет в 4 раза медленнее, чем "обычные" люди.
1. Для дополнительной аутентификации (по документам, при покупке авиабилетов и т.п.). Тут нужно хранить именно дату, и сравнивать только дату, без учёта часовых поясов.
2. Для определения возраста. Опять же, практически (и юридически) обычно часовые пояса не учитываются, а дата из документов считается по локальному часовому поясу. Да и случаи, при определение возраста разница в несколько часом имеет какое-то значения очень редки. Соответственно также нужно хранить только дату.
3. Поздравления с днем рождения и т.п. Какой-либо юридической значимости, обычно, не имеют, поэтому как хранить — непринципиально. Тем более, что разные люди по разному этот день начинают праздновать: кто-то в 00:00, кто-то знает точное время рождения, кто-то «как проснутся, с утра».
Автор не придал значения тому, как определена дата рождения (дата; время и часовой пояс роли в жизни не играют) и когда она отмечается (одинаковый день со смещением по годам). Не быть UX дизайнером :)
Сколько Новых Годов существует? Если лететь в самолете, можно умудриться отпраздновать дважды. С ДР не мешает ничто проделать то же самое.
Юридически... лезьте в нормы и документы называется. Если у страны несколько часовых поясов, то консервативно применяя локальную часовую зону компании на сервере (пользователь с дальнего востока, а считаем по МСК), думаю ничего не будет, к чему можно будет придраться (даже если пользователь из Европы и мы ему МСК временем на час-два раньше дадим совершеннолетие, например).
Если равняться на пользователя, учитывая его местонахождение или заданный часовой пояс... ну и что? Для оповещений - это и надо делать, а плюс-минус 12 часов - создайте юридический прецедент, если такового нет, с радостью посмотрим.
Короче: хранить дату, в зависимости от задачи применять часовой пояс пользователя или компании.
Если стоит задача поминутной проверки кто раньше родился - Катя или Саша, заморачивайтесь, как выше написали, не только точной датой+временем, но и местоположением (а то вдруг часовой пояс сменят, и вы не сможете сверить с Раулем, который родился в Испании в тот же час)
Многие (если не все) базы данных умеют хранить дату без таймзоны. Вот в таком виде и надо ее хранить. Тогда дата рождения не поплывет у клиентов в разных часовых поясах. А вот момент, когда поздравлять пациента - надо вычислять с учетом таймзоны поздравляемого - наступила эта дата там, или нет. И еще надо позаботиться о том, чтобы кроме СУБД еще какой-нибудь слой (backend или frontend) не произвел преобразование даты вида "дд.мм.гггг 00:00:00" в таймзону клиента.
Кстати, недавно столкнулся с паспортом (настоящим), где дата рождения была указана как "00.00.1946" (именно так, с нулями), которую в поле типа Дата и подобные внести никак нельзя. Я так понимаю, в МВД для даты рождения используется просто строка. И в данном случае, видимо, точная дата рождения была утеряна.
Корректнее написать просто: дату/время надо всегда запрашивать и обрабатывать с учётом контекста применения. В частности, для даты рождения имеет смысл отдельная сущность, которая напрямую (конверсиями и т.д.) не связана с ISO датой/временем.
Локальное время и дата рождения или зачем UTC