Существует ли когда-нибудь серьезное основание сохранить время не в UTC?
Вот ссылка на довольно хороший документ, объясняя все различные способы решить Вашу проблему (хотя многие из них не могут использоваться, так как Вы не можете изменить существующую хранимую процедуру.)
, Как Обменяться данными Между Хранимыми процедурами
, ответ Gulzar будет работать (он документируется в ссылку выше), но это будет стычкой для записи (необходимо будет определить все 80 имен столбцов в @tablevar (col1...) оператор. И в будущем, если столбец добавляется к схеме или выводу, изменяется, это должно будет быть обновлено в Вашем коде, или это будет ошибка.
7 ответов
В общем, я считаю, что лучше использовать UTC. Иногда может потребоваться местное время. Тогда я бы предпочел использовать информацию о часовом поясе в формате UTC +.
В общем, время может быть очень сложным для повторяющихся событий, и вам следует очень тщательно анализировать варианты использования.
Представьте себе повторяющуюся встречу каждый вторник в 9:00. . Если летнее время изменится, встреча все равно должна состояться в (новом) 9:00 утра.
Но не добавляйте к встрече парней из Франции. Для них встреча в 18:00. И они меняют летнее время по другому правилу.
Когда вы меняете летнее время, они этого не делают, поэтому какое-то время (пока Франция не изменит летнее время) кто-то должен отключиться: либо ваша встреча будет в 10 утра, что их останутся в 18:00 или оставят ваш в 9:00 и переедут в 17:00. Другого пути нет, компьютеры тут ни при чем.
Как приложение будет решать, кого «починить»? Это группа, в которой больше всего участников? (1 парень в США против 20 во Франции?) Или дело в важности человека? (что, если 1 парень в США - генеральный директор?)
Как вы храните эту информацию? Лучшее решение - использовать UTC + один «главный часовой пояс». Пользователи в "главном часовом поясе" побеждают (оставайтесь фиксированными).
Все может быть довольно сложно, но в целом я обнаружил, что UTC решает больше проблем, чем вводит.
Чтобы прояснить (очень верно: - ) точка из fjsj : под «основным часовым поясом» я подразумеваю точную зону, включая информацию о том, активно или нет летнее время.
Если вы просто сохраняете PT (Тихоокеанское время) , тогда мало.
PST (Тихоокеанское стандартное время) или PDT (Тихоокеанское летнее время).
Вероятно, даже лучше не думать о повторяющихся собраниях как о «фиксированной точке времени», выраженной в секунды / миллисекунды от «эпохи». Языки программирования (наконец) начали перенимать концепции JodaTime.
Я бы сказал, что это зависит от приложения. Я работаю над космическими физическими моделями ионосферы и магнитосферы. Мы работаем с магнитным местным временем, сохраняя дату и время как Модифицированные юлианские дни .
Сигналы тревоги и запланированные задачи иногда сохраняются по местному времени, поэтому на них не влияет переход на летнее время или изменения часового пояса.
Во встроенной системе вы вполне можете получать время из источника в виде некоей формы «тики прошедшей эпохи».
Если время обновляется относительно часто и отображается относительно редко, тогда вы можете сохранить его таким же образом, как он был вам предоставлен, и преобразовывать его для отображения только при необходимости.
В целом, тем не менее, лучше всего использовать UTC, если нет других соображений.
Когда-нибудь ? Я уверен, что в некоторых единичных случаях есть веские причины. В целом, тем не менее, хранить UTC намного лучше, чем местное время, поэтому я бы рассматривал UTC как позицию по умолчанию, если не было особых соображений.
Когда вы уверены, что будет использоваться только местное время.
UTC - это стандарт хронометража с точностью и точностью TAI , но с добавлением дополнительных секунд в через нерегулярные интервалы, чтобы точно отслеживать среднее солнечное время (UT1).
Если система, с которой вы работаете, не может обрабатывать дополнительные секунды, то Международное бюро оценок и измерений рекомендует использовать TAI вместо UTC.