|
Повідомлення створено: 02. 11. 2010 [13:34]
|
|
andrelek
Андрей Полевой
Автор теми
Зареєстрован(а) с: 13.12.2008
Повідомлення: 210
|
Здравствуйте!
Сохраняю показания накопителя (значение постоянно растет) на базу данных (MySQL) и на файловую систему.
При переходе на зимнее время архивация на файловую систему произвелась корректно, просматривал в QTконфигураторе, время с 3.00 по 3.59 повторяется 2 раза и архивируемое значение увеличивается без резких скачков. рис1
А вот архивация на базу данных происходит как-то странно, время если смотреть в QTконфигураторе также повторяется с 3.00 по 3.59 2раза, но значения архивируемого атрибута в промежутках с 3.00 по 3.59 равны между собой и относятся к уже переведенному времени, т.е ко второму промежутку с 3.00 по 3.59. рис2. Хотя если просмотреть таблицу с пом sql-запроса, то там нет строк с одинаковым временем, для вышеуказанных промежутков времени.
В настройках буфера:
Жесткая сетка времени буфера да
Вкладений файл
Рис1.png (Тип файлу: image/png, Розмір: 69.82 кілобайтів) — 2013 завантажень
Рис2.png (Тип файлу: image/png, Розмір: 70.54 кілобайтів) — 2015 завантажень
|
|
Повідомлення створено: 02. 11. 2010 [15:15]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
Дело в том, что время в поле Datetime БД "MySQL" хранится в виде:
Тип данных DATETIME используется для величин, содержащих информацию как о дате, так и о времени. MySQL извлекает и выводит величины DATETIME в формате 'YYYY-MM-DD HH:MM:SS'. Поддерживается диапазон величин от '1000-01-01 00:00:00' до '9999-12-31 23:59:59'. (''поддерживается'' означает, что хотя величины с более ранними временными значениями, возможно, тоже будут работать, но нет гарантии того, что они будут правильно храниться и отображаться).
Т.е. нет информации не о временном поясе, не о летнем времени. А значит нужно хранить его в UTC, чего сейчас не делается. Это значит, что дата из БД без коррекции будет не адекватна для локального местоположения.
P.S. По началу там время указывалось в лоб, т.е. меткой времени в UTC от эпохи UNIX. Кое кому это не понравилось, вот и получите. :)
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 02. 11. 2010 [16:27]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
Исправил и слил изменения в рабочую (r1169) и стабильную ветки (r1170).
Теперь время в БД будет лежать в UTC, но существующие архивы сдвинутся!
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 03. 11. 2010 [10:09]
|
|
andrelek
Андрей Полевой
Автор теми
Зареєстрован(а) с: 13.12.2008
Повідомлення: 210
|
Спасибо!
А нельзя ли добавить в настройки архиватора флаг с помощью которого можно было бы указывать каким образом хранить время в базе?
|
|
Повідомлення створено: 03. 11. 2010 [13:11]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"andrelek" wrote:
А нельзя ли добавить в настройки архиватора флаг с помощью которого можно было бы указывать каким образом хранить время в базе?
Всё можно добавить, включая:
- чтение информации из БД для восстановления перечня архивов в архиваторе на БД;
- оптимизацию структуры БД на предмет наличия поля микросекундного времени.
Только мне сейчас это не интересно.
Если Вам это нужно то сюда: http://oscada.org/ua/forum/topics/zapros_funkcii и не забыть предложить компенсацию затраченного времени. :)
Learn, learn and learn better than work, work and work.
|
