|
Проблема с планированием операций: конец операции "сегодня", начало следующей - "завтра"
|
|||
---|---|---|---|
#18+
Часть операций планируется с точностью до дня, часть - с точностью до часов/минут. Сейчас сделано так: для операций, которые планируются с точностью до дней, в справочнике указывается длительность в днях, при этом программа считает начало операции в 00:00, а окончание в 23:59:59. Возникает проблема: получается, что следующая за окончившейся в 23:59:59 операция начинается таки в 23:59:59 "предыдущего дня". Планировшику выводятся даты и его начало операции в "предыдущий день" категорически не устраивает. Вопрос: а есть какие-либо общеупотребительные методы/подходы решения такой задачи/проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2010, 14:51 |
|
Проблема с планированием операций: конец операции "сегодня", начало следующей - "завтра"
|
|||
---|---|---|---|
#18+
Aleksey Kh., Если бы учитывалась загрузка то последняя точка 23.59.59.999 была бы занятой. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2010, 15:01 |
|
Проблема с планированием операций: конец операции "сегодня", начало следующей - "завтра"
|
|||
---|---|---|---|
#18+
авторЕсли бы учитывалась загрузка то последняя точка 23.59.59.999 была бы занятой Не понял. Вообще, конечно, "свой" велосипедт изобретен: Tнач.след.опер = Токон.пред.опер. + 1 сек. Но вопрос не в изобретении, а в общепринятых ("правильных") подходах. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2010, 16:14 |
|
Проблема с планированием операций: конец операции "сегодня", начало следующей - "завтра"
|
|||
---|---|---|---|
#18+
авторпри этом программа считает начало операции в 00:00 автор следующая за окончившейся в 23:59:59 операция начинается таки в 23:59:59 заканчивайте в 00.00, делов-то ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2010, 16:22 |
|
Проблема с планированием операций: конец операции "сегодня", начало следующей - "завтра"
|
|||
---|---|---|---|
#18+
Aleksey Kh., ну как календари то реализованы? если конец периода = 23.59.59.999 и начало новой палки совпадает с этой точкой, то вы берете следующий каленьдарный период (так как нет в прошлом периоде доступного места = начпериода=конпериода) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2010, 17:59 |
|
Проблема с планированием операций: конец операции "сегодня", начало следующей - "завтра"
|
|||
---|---|---|---|
#18+
заканчивайте в 00.00, делов-то начинать операцию 01.01 00:00, а заканчивать 02.01 00:00? так не годится, т.к. тогда диспетчер увидит начало 01.01, а окончание 02.01 - для него это длительность в два дня. ну как календари то реализованы? Есть расписание работы подразделения (которое выполняет операцию), но там просто задается работает подразделение в такой-то день или нет. Но за мысль спасибо, подумаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2010, 22:25 |
|
Проблема с планированием операций: конец операции "сегодня", начало следующей - "завтра"
|
|||
---|---|---|---|
#18+
Aleksey Kh., ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2010, 23:40 |
|
Проблема с планированием операций: конец операции "сегодня", начало следующей - "завтра"
|
|||
---|---|---|---|
#18+
Aleksey Kh.Вопрос: а есть какие-либо общеупотребительные методы/подходы решения такой задачи/проблемы. Не знаю как насчёт "обще", но имхо всё вполне очевидно: надо мыслить полуоткрытыми интервалами, то есть для операции с началом в T1 и длительностью X операция занимает [T1; T1+X), следующая операция, соответственно, [T1+X; T2). Итого всё, что остаётся - решить как выводить интервал в интерфейсе. Ответ: так, как пользователь хочет его видеть. Что никак не связано с его хранением в БД. Довольно естественное решение - выводить [T1; T1+X) как [T1; T1+X-1сек]. Подчёркиваю: выводить, а не хранить. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2010, 18:04 |
|
|
start [/forum/topic.php?fid=33&fpage=29&tid=1548183]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
24ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 117ms |
0 / 0 |