У кого как софтина реагирует на перевод времени?

SIMPLicity_

У кого как софтина реагирует на перевод времени?Используете ли Вы на SQL-серверах ИСКЛЮЧИТЕЛЬНО независимые настройки времени? --------------------------No ROM Basic...
10 ответов

SIMPLicity_

SIMPLicity_,Честно. Тему в программирование.Для задач 24/7 это - вечная жора. -((И причин много, чтобы легко обойтить.


SIMPLicity_

Мне тут полегче - в прошедшую ночь максимум что произошло - не отработали несколько job-ов (они сработают в будущую ночь, потери данных не должно быть ибо эти дни "не очень" рабочие). При обратном переходе -наоборот, ну отработаются два джоба повторно...Но уже "некоторым" (из тех, у кого 7х24) как-то приходится "выкручиваться"; и проблему тут, скорее всего, не весной а осенью...Однако вот что напрягает - если на железяке, где крутится MSSQL не использовать переход времени, то в интересующей меня софтине операторы будут видеть свои документы с датой +/- час (в зависимости от момента отключения "смены летнего/зимнего времени"). В общем да, наверное это в "Программирование".Спасибо, Siemargl, за комментарий.--------------------------No ROM Basic...


SIMPLicity_

Перевод времени легко обходится если джобы не настраивать на диапазон с 2:00-3:00 :)


SIMPLicity_

Перевод времени легко обходится если джобы не настраивать на диапазон с 2:00-3:00 :)
+1PS А я типа всегда себя ловил на подсознательной нелюбви к этому временному диавазону ...


SIMPLicity_

Перевод времени легко обходится если джобы не настраивать на диапазон с 2:00-3:00 :)
Я так понимаю осенью время переводится с 2 часов ночи на три...А весной с 4 утра на те же три... Итого два часа диапазона выпадает :-)


SIMPLicity_

С чего два то?Весной с 2 на 3, а осенью с 3 на 2. Итого 1 час.Хотя в России, наверное, осенью уже никуда двигать время не будут.


SIMPLicity_

С чего два то?Весной с 2 на 3, а осенью с 3 на 2. Итого 1 час.Хотя в России, наверное, осенью уже никуда двигать время не будут.
Ну да - весной выпадают джобы, выполняющиеся, например, в 2.15а осенью дважды выполнятся джобы, опять-таки, стартующие в 2.15Ну плюс и граничное время 2:00:00сек. и 3:00:00сек.


SIMPLicity_

На 3 серваках репликации повисли, 28-го в 3 часа ночи. Интересно только, почему остальные отработали нормально, а эти зависли и висели до понедельника.


SIMPLicity_

ABV, не уверен, но вероятно, что произошла ошибка получения времени старта (окончания) репликации - например, почему-то репликацияя могла закончится раньше чем началась... При малом расхождении во времени это проходит незамеченным, а вот при расхождении на час... Это мое личное предположение, навеянное результатом выполнения:
SELECT CONVERT (time, SYSDATETIME())
 ,CONVERT (time, SYSDATETIMEOFFSET())
 ,CONVERT (time, SYSUTCDATETIME())
 ,CONVERT (time, CURRENT_TIMESTAMP)
 ,CONVERT (time, GETDATE())
 ,CONVERT (time, GETUTCDATE());
(BOL Shit) 23:23:52.3906250 23:23:52.3906250 19:23:52.3906250 23:23:52.3900000 23:23:52.3900000 19:23:52.3900000 от идеального случая: 23:26:26.7500000 23:26:26.7500000 19:26:26.7500000 23:26:26.7500000 23:26:26.7500000 19:26:26.7500000далеко, хотя такое и бывает...А вот если попадает на границу часа...Это моё сугубо личное мнение, вероятно даже что ошибочное...


SIMPLicity_

........... skip - skip - skip .........от идеального случая: 23:26:26.7500000 23:26:26.7500000 19:26:26.7500000 23:26:26.7500000 23:26:26.7500000 19:26:26.7500000далеко, хотя такое и бывает.......
А может быть и так:23:32:47.7343750 23:32:47.7343750 19:32:47.7343750 23:32:47.7270000 23:32:47.7270000 19:32:47.7330000(запрос всё тотже)...