- В этой теме 27 ответов, 5 участников, последнее обновление 9 лет назад сделано
.
-
Сообщения
-
Михаил, так может вы распишите унаследованный из Delphi формат, а мы уже подгонимся ?
Или если DateTime.ToOADate() окажется достаточно близок к нему то произойдет переход ?Михаил. Да с нестандартными данными идея хорошая. Но мне нужно просто сформировать дневной архив из часовых данных. Я посмотрел исходники, по идее проблем возникнуть не должно. Сделать по аналогии с часовым срезом и добавить дорасчетный и ТС. Единственное изменить пару условий, где проверяется минутный или часовой срез. Но это так на вскидку, конечно надо пробовать.
И можно еще вопрос? Дата записи среза в файл формируется на основании имени файла? Я просто хотел сдвинуть начало суток(Газовые сутки) на 10 часов утра. Так вот писать в нужный файл получается(т.е. на день назад) время соответствует а вот дата смещается.Не знаю понятно ли объяснил. К примеру мне нужно чтобы данные за 17.03.2016 08:37:00 записывались в файл m160316.dat. Они туда пишутся, но дата получается 16.03.2016.
Дата берётся из имени файла. На мой взгляд, нужно колдовать с отображением, чтобы получить контрактный час (кажется так это смещение называется).
Реализация формата даты:
https://github.com/RapidScada/scada/blob/master/ScadaData/ScadaData/Data/Arithmetic.csЕсли он не совпадёт с DateTime.ToOADate(), то нужно от него уходить.
Думал об этом, но куча неудобств возникает. Особенно если делать дневные архивы. У нас контрактный час всегда 10:00 поэтому удобнее сразу так и писать в базу, удобно отображать срезы и так далее.
Т.е. в принципе я могу переделать механизм записи добавив некий инкремент(Контрактный час) в настройки scada-сервера?Михаил, проверьте пожалуйста, соответствует ли это варианту Delphi.
В С# ToOADate, FromOADate тоже вроде пляшет от 30 декабря 1899 года17.03.2016 15:38:47 — #03#59#B1#DC#D4#B9#E4#40, 42446,6519400347
17.03.2016 15:38:52 — #26#EA#2D#DD#D4#B9#E4#40, 42446,6519994329
17.03.2016 15:39:28 — #0E#62#8E#E0#D4#B9#E4#40, 42446,6524116435Т.е. в принципе я могу переделать механизм записи добавив некий инкремент(Контрактный час) в настройки scada-сервера?
Думаю, что это может привести к непредсказуемым ошибкам. Будет надежнее, если Вы разработаете веб страницу, которая будет отображать данные в нужном Вам виде на основе существующего механизма работы с данными.
Михаил, проверьте пожалуйста, соответствует ли это варианту Delphi.
В С# ToOADate, FromOADate тоже вроде пляшет от 30 декабря 1899 годаНапишите консольное приложение, которое будет сравнивать double, полученные от DateTime.ToOADate() и Arithmetic.EncodeDateTime() на большом наборе значений даты и времени. Проверка вручную ничего не гарантирует.
Сравнил, отличаются в миллисекундах вероятно.
18.03.2016 13:21:26______18.03.2016 13:21:33______18.03.2016 13:21:40
42447,5565534375_________42447,5566373727_________42447,5567141088
42447,5565534412_________42447,5566373812_________42447,5567141101
18.03.2016 13:21:26______18.03.2016 13:21:33______18.03.2016 13:21:4018.03.2016 13:21:45______18.03.2016 13:21:50
42447,5567719907_________42447,5568361806
42447,5567719954_________42447,5568361889
18.03.2016 13:21:45______18.03.2016 13:21:501 дата (date1) — получена по DateTime.Now
1-ый double (dd) получен при помощи date1.ToOADate()
2-ой double (dd1) получен при помощи Arithmetic.EncodeDateTime(date1)
2-я дата получена при помощи DateTime.FromOADate(dd1)Так что если миллисекунды не так важны, то даты и время вроде совпадают, хотя и есть отличия в самих double. надо подольше погонять, появится ли расхождение в секундах в какие-то моменты времени. Либо это просто не идеальный расчет миллисекунд в какой-то из формул.
Скорее всего один из методов просто обрезает миллисекунды.
Только какой из двух не проверял.p.s. предположение.
ща проверю 🙂
Миллисекунды либо равны, либо в оригинальном варианте DateTime.Now на 1-ну миллисекунду меньше.
Там еще что-то сидит, кроме этого, что не учитывает функция Delphi, не связанное с временем как таковым.
- Вы должны авторизироваться для ответа в этой теме.