Linux за българи: Форуми

Здравейте,
Ситуацията е следната:
Olinuxino Lime2 с инсталиран armbian, apache2, php7, mariadb Ver 15.1 Distrib 10.3.27-MariaDB. Имам скрипт който се стартира на всяка минута, взема определена информация и я вкарва в базата.
Едно от полетата на базата е timestamp и се попълва автоматично от базата. Записите стават по българската часова зона( UTC+2,), т.е. когато запише нещо в 14:00 българско време то то се записва  със стойност на полето timestamp с коректната стойност за 14:00. До тук всичко е супер. Базата се пълни с коректни данни и всичко е "цветя и рози".
Следващата стъпка е grafana, която е инсталирана за да визуализира данните събрани в тази таблица. Проблема е, че grafana отнякъде си добавя още 2 часа, и събитие което в базата е записано като случило се в 14:00, тя го отбелязва и показва в 16:00.
Навсякъде локализацията е  София/България. Разбирам, че ако в базата данни се записва с UTC време, а не UTC+2, графиките ще са коректни, но някак си не ми се иска да го оправям по този начин.
Някой сблъсквал ли се е до сега с подобен проблем и ако да, как е процедирал за да го разреши.

А в системното време (в биоса) на Olinuxino какво време е зададено UTC или вече коригираното 14:00.
Трябва в биосите да се задава UTC време. Аз никога не съм се занимавал с такива платчици и не знам как се сетва и дали изобщо може...Ама на сегашните компютри в биоса трябва да се задава UTC време. Не е като едно време, когато всеки си настройваше точното локално време.

Принципът е че всичко трябва да по UTC, а пък след това системата а и отделните програми да си корегират времето за правилно изобразяване според часовата зона на ОС-а. (Или според часовата зона на самата програма)

Един път и аз така се бях омотал....Едни програми показваха +2 часа, други (php--то) +4 ....абе пълна каша.

Разбирам, че ако в базата данни се записва с UTC време, а не UTC+2, графиките ще са коректни

Ами в документацията пише, че TIMESTAMP се съхранява като UTC време. (различно е от DATETIME)

MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.)

Тука един много хубаво го е обеснил за TIMESTAMP и часовата зона.
https://www.mysqltutorial.org/mysql-timestamp.aspx/

има и една mysql променлива с която това може да се контролира.
т.е. може да влезеш в mysql конзолата, да напишеш
SET time_zone='+02:00';
SELECT ... from ...;

и да видиш какво време ще върне и да определиш виновника. Биоското време ли е проблема, скрипта ли ти бута неправилни дати или grafana ги изобразява неправилно.

Платката няма биос,  процесора е ARM и май там има някакъв файл в който са описани устройствата.
Като изпълня заявка селект в конзолата и последния запис ми го дава с коректния за бг локализацията час, за това писах че записва по българско време в timestamp колоната.
Ето снимка направена преди минути на изхода на селект заявката в конзолата цък ($2) а ето как графана показва същата колона цък ($2)
П.П. двете снимки са направени с около 20 мин разлика

Просто записвай UTC в базата данни и Grafana ще си го handle-ва във времевата зона, която си конфигурирал. Не си усложнявай живота.  ;)

Повече ($2) по темата.

Просто записвай UTC в базата данни и Grafana ще си го handle-ва във времевата зона, която си конфигурирал. Не си усложнявай живота.  ;)

Повече ($2) по темата.

Усложних го малко, зададох време за показване на данните от "now - 22h"  до "now +2h" и избрах часова зона UTC, сега показва коректни часовете на събитията