- В этой теме 82 ответа, 6 участников, последнее обновление 1 год, 9 месяцев назад сделано
.
-
Сообщения
-
Именно, что операторы в разных зонах обычно договариваются по какому времени все отслеживать. и они не должны потом отнимать договоренное время от отображаемых в системе.
с интервалами случился косяк 🙂 15 часов они и в Африке 15 часов, а получается что в формулах надо приводить этот интервал к 12-ти часам, чтобы получить по Москве правильные 15 часов. 🙂
Не по UTC, а по тому часовому поясу, который тебе нужен. Хочешь ставь свой, а хочешь дочерней системы. Честно говоря не вижу проблемы. Просто используешь всегда ToUTC или FromUTC в драйверах, модулях или формулах. Должна быть какая-то общая величина. Представь если корабль пересекает пол мира, какое тут нафиг локальное время? У него каждый день может быть новый часовой пояс :). Тут вообще запутаешься в расчетах, если не будет привязки по единому времени на двух серверах.
с интервалами случился косяк ? 15 часов они и в Африке 15 часов, а получается что в формулах надо приводить этот интервал к 12-ти часам, чтобы получить по Москве правильные 15 часов. ?
Ну тут при реализации формулы конечно нужно все предусматривать.
И как предусмотреть в формулах интервал? Уменьшать количество часов в зависимости от договоренного часового пояса?
Ну бред же, когда тебе WEB к формату Time автоматом прибавляет пилюлю 🙂
Тогда нужен формат отображения что-то вроде
TimePure — чистое время, чтобы Сервер при передачи WEB или сам WEB не приводил к localTime.DatePure, DateTimePure в придачу.
Ну и с появлением формата Interval по умолчанию чтобы ничего не прибавлялось.и еще в придачу к Длине данных добавить Структуры каким-то образом.
Чтобы можно было выставлять Формат для каждого элемента структуры.
И чтобы были разные формулы для каждого элемента структуры.Пусть даже для этого нужна будет дополнительная таблица в БД.
Уж проверить на строку или число ячейку Тип Данных не думаю, что такая уж проблема.
И если там просто 3 — значит это массив.
А если там S3 — значит это структура с длиной 3 (количество переменных) — типа зырь туда, там и описание структуры и формулы для каждого элемента.Ну это уже здравствуй Json + Javascript. Я пишу на нем для психологической разгрузки, когда можно тяжелое разделить на синее и прибавить фамилию и все это в одном массиве :). Структуры — это наверное уже RapidScada7 :).
Ну почему же v7 ?
Это зависит как можно преобразовать ячейку «Длина данных» ее обработку в текущей версии.
Если ее можно преобразовать в строку и проверять что там, то не вижу особой проблемы.
Большая проблема наверное будет это новая таблица под структуру для вызова формул на каждый элемент и указания Формата каждого элемента.Если правильно понимаю, в настроечной БД мы имеем всего один канал, а таблица каналов сервера создается при передаче Серверу, где согласно длине данных просто копируются формулы, форматы и т.д.
Так почему при добавленной таблице «Стуктура» не выбирать отдельно определенные формулы и форматы?Это же элементы настройки Администратора по сути.
Я не говорю про какие-то сложности в виде различных типов данных, пусть сами данные структуры так же будут в double, как и все каналы того же массива. Это не изменит концепцию пока что.Да, собственно формула периода для массива длиной 2, тип данных — пусто или Doublе, Формат — D
public double FromTS(double sec) { TimeSpan ts = TimeSpan.FromSeconds(sec); double time = EncodeDate(new DateTime(1, 1, 1, ts.Hours, ts.Minutes, ts.Seconds)); double[] mts = {ts.Days, time}; return mts[ArrIdx]; }На 2-й канал массива делаем расчетный канал с формулой Val(126) при начальном канале 125 в котором формула FromTS(Cnl) (или значение в double полученных секунд)
И указанием Формата — Time (Время) — ну сами там думайте, как отнимать часы из-за часового пояса…На скрине все видно.
Исходим из того, что Сервер работает и хранит данные по времени UTC. Часовые пояса обрабатываются при отображении на клиенте.
Если драйвер выкачивает архивы из прибора, у которого свой часовой пояс, то в драйвере должна быть настройка, которая учитывает часовой пояс и переводит время в UTC для передачи архивов на Сервер. Если прибор способен этот часовой пояс сообщить, то вместо параметра настройки можно его запросить.
Ну а что делать с формулами интервалов в таком случае?
И с формулами времени в том числе?я не говорю про драйвера сейчас. А о том, что не так то просто изменить в формуле.
Ок, дату время можно привести к UTC и все будут видеть своё.Интервал в данном случае как?
А то выглядит как «Гена, нам подарили 10 апельсинов, свои 8-мь я уже съел» 🙂
Кстати можно даже не менять тип данных ячейки Длина данных.
Просто по дабл клику при вызове добавить дополнительную вкладку для настройки типов каналов и хранить где-то в отдельной таблице описание структуры.А система видя, что длина данных > 1 просто будет проверять отдельную таблицу — создано ли там описание структуры для конкретного канала массива или нет.
Дешево и сердито. А что уже Серверу передается, а не все ли равно?
Ну это при условии, что все каналы так же double и полностью повторяют параметры Cnl
Хоть какая-то гибкость.У меня сделано так:
В расчетный канал записывается время изменения чтобы не потерять данные при остановке сервера:
PrevVal(219) != Val(219) ? UtcNow(): Val()Далее вычисляется интервал. Форматирование здесь можно сделать уже какое захочется. В моем случае нужно было выводить только одну составляющую времени.
public string EventTime(int cnlNum)
{
DateTime dt = DateTime.FromOADate(Val(cnlNum));
TimeSpan delta = DateTime.UtcNow — dt;if(delta.Days > 0)
return $»{delta.Days} day»;
else if(delta.Hours > 0)
return $»{delta.Hours} hour»;
else if(delta.Minutes > 0)
return $»{delta.Minutes} min»;
else
return $»{delta.Seconds} sec»;
}
- Для ответа в этой теме необходимо авторизоваться.