EnglishУкраїнськаmRussian
Login/New
Topic with no new replies

[BugFixed] Переход на зимнее время


Author Message
Written on: 02. 11. 2010 [13:34]
andrelek
Андрей Полевой
Topic creator
registered since: 13.12.2008
Posts: 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-запроса, то там нет строк с одинаковым временем, для вышеуказанных промежутков времени.
В настройках буфера:
Жесткая сетка времени буфера да
Attachment

Рис1.png (File type: image/png, Size: 69.82 kilobytes) — 1978 downloads
Рис2.png (File type: image/png, Size: 70.54 kilobytes) — 1984 downloads
Written on: 02. 11. 2010 [15:15]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3747
Дело в том, что время в поле 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.
Written on: 02. 11. 2010 [16:27]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3747
Исправил и слил изменения в рабочую (r1169) и стабильную ветки (r1170).
Теперь время в БД будет лежать в UTC, но существующие архивы сдвинутся!

Learn, learn and learn better than work, work and work.
Written on: 03. 11. 2010 [10:09]
andrelek
Андрей Полевой
Topic creator
registered since: 13.12.2008
Posts: 210
Спасибо!
А нельзя ли добавить в настройки архиватора флаг с помощью которого можно было бы указывать каким образом хранить время в базе?
Written on: 03. 11. 2010 [13:11]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3747
"andrelek" wrote:

А нельзя ли добавить в настройки архиватора флаг с помощью которого можно было бы указывать каким образом хранить время в базе?

Всё можно добавить, включая:
- чтение информации из БД для восстановления перечня архивов в архиваторе на БД;
- оптимизацию структуры БД на предмет наличия поля микросекундного времени.

Только мне сейчас это не интересно.
Если Вам это нужно то сюда: http://oscada.org/ua/forum/topics/zapros_funkcii и не забыть предложить компенсацию затраченного времени. :)

Learn, learn and learn better than work, work and work.



25514