Имхо, жирнейший довод все таймстампы получать и хранить в UTC

Поручик ·· РжевскийFr0sT-BrutalИмхо, жирнейший довод все таймстампы получать и хранить в UTCNLS то всё одно отсутствует
Не очень понял, что ты имеешь под NLS, но если есть возможность полностью убрать timezone hell - глупо ею не воспользоваться. Не знаю, каким надо быть мазохистом, чтобы лавировать в этом безумии постоянных смен смещений и режимов DST.
P.S. Где проголосовать за CURRENT_UTCTIMESTAMP?

kdvFr0sT-BrutalГде проголосовать за CURRENT_UTCTIMESTAMP?
во-первых, не за UTCTIMESTAMP, а TIMESTAMP_UTC.
Как мне кажется, ты про тип, а я про сист. переменную. Если не так, то двойное подчеркивание не очень красиво смотрится, но не суть.
Ну а тип это хорошо, но решение будет нестандартным, плюс породит целую кучу проблем вроде "как мне перегнать это время в мое локальное", "как мне сравнить два локальных времени на сервере" и прочее.

kdvCURRENT_UTCTIMESTAMP - это запредельный звездец.
Дело вкуса...
А CURRENT_TIMESTAMP_UTC - это прекрасно читаемое имя, особенно уже при наличии CURRENT_TIMESTAMP. Если тебя корежит от двух подчеркиваний, то почему не корежит от одного?
Единственное, что смущает - вроде бы больше идентификаторов с двумя _ нет.
Корректную работу с UTC, в принципе, можно реализовать самому. Определить домен, создать 2 функции для перевода в локальное время и обратно (причём для каждой базы можно гибко задавать часовой пояс (например через переменную БД), если вдруг база на хостинге). Работы на несколько часов.
По-хорошему, часовой пояс - это свойство клиента, а не базы.
Я и говорю - без полноценного введения NLS, нефиг даже тужиться
А еще лучше - без светлого будущего во всем мире нефиг тужиться, а то пашешь-пашешь, а потом вдруг апокалипсец! И все усилия насмарку.
В идеале дата должна быть жестко задана в инвариантном UTC + опциональный часовой сдвиг, д.б. полный набор функций для работы как с абсолютным, так и локальным значением не только в SQL, но также и на клиентах. Но слона надо есть по кускам.