Проблемы масштабируемости:
Прежде всего, отметим, что вам не следует экономить местное время в своей базе данных. Ваша база данных должна иметь как можно меньшую предвзятость, т.е. не должна быть привязана к местному часовому поясу. Почему? Когда вы масштабируете свое решение и внедряете его в облачную службу, такую как AWS, и вам приходится создавать экземпляры нескольких серверов в нескольких размещенных зонах, которые существуют в разных местах по всему миру, ваша база данных сразу же окажется в очень плохой ситуации, и экономьте время недетерминированно c, что дает вам много будущих ошибок, которые нужно убить.
Решение :
Начните только с , сэкономив UT C время в вашей базе данных : moment.utc() || new Date(). Затем во внешнем интерфейсе (при условии, что он у вас есть) браузер пользователя имеет локализованный часовой пояс, встроенный в его среду выполнения. Поэтому у вас есть несколько вариантов управления потреблением приложением пользователя.
Варианты решения
В вашем коде переднего плана moment().format('hh:mm') будет местным часовым поясом, установленным браузером / телефоном / устройством, независимо от того, что использует данные БД.
Если вы дадите тот же самый go из 1, DB ut c time, moment(<time from db as UTC>).format('hh:mm') вы увидите только отформатированное время UT C.
Теперь, если вы хотите, чтобы время БД (UT C) отображалось как местное время вашему соответствующему пользователю, вы можете сделать moment(val).utcOffset('-0400').format('hh:mm')
Главный вывод: вам нужно удалить временное смещение вашего сервера из решения. В противном случае у вас будут действительно плохие проблемы. И вам необходимо учитывать смещение времени браузера в вашем решении, если время в вашей БД будет использовано приложением, ориентированным на пользователя.
ПРИМЕЧАНИЕ: метод .format() имеет множество конфигураций. Я выбрал hh:mm просто для интуитивного примера. Очевидно, это следует изменить в соответствии с вашими потребностями.