Heidisql: Неверное отображение временной метки в качестве значения даты в сетке

Созданный на 31 янв. 2018 · 5Комментарии · Источник: HeidiSQL/HeidiSQL

Установка «Это столбец метки времени UNIX» активна в параметрах представления таблицы, чтобы увидеть метку времени UNIX как представление даты.

Ожидаемое поведение

Следующее (временная метка unix) значение сохраняется как BIGINT в базе данных:
1098655200
GMT: воскресенье, 24 октября 2004 г., 22:00:00
Берлин: понедельник, 25 октября 2004 г., 12:00:00 AM GMT + 02: 00 DST.

Сетка должна отображаться здесь:
2004-10-24 22:00:00 (GMT) или
2004-11-25 00:00:00 (Локально)

Текущее поведение

Сетка показывает:
2004-10-24 23:00:00

Кажется, что текущий часовой пояс используется для отображения значения, и это GMT + 1 на сегодняшний день (2018-01-31) в Германии, без перехода на летнее время.
Значение должно отображаться в соответствии с часовым поясом в указанную дату, которая была GMT + 2, летнее время активно.

Действия по воспроизведению

Создайте столбец BIGINT и вставьте значение 1098655200
Установите для параметра «Параметры представления сетки» значение «Это столбец с отметкой времени UNIX».
Вы получите: 2004-10-24 23:00:00
Ожидается: 2004-11-25 00:00:00

Контекст

Версия HeidiSQL: 9.5.0.5196
Система баз данных + версия: MariaDB 10.2.12
Операционная система: Windows 10, часовой пояс Европа / Берлин

bug

Источник

mpaland

👍2

Все 5 Комментарий

привет @mpaland , ваш MariaDB работает с правильным
Я не обрабатываю много преобразований, timestamp пишет в UTC, не так ли? а MySQL конвертирует в ваш часовой пояс?

Я пытался воспроизвести, но на серверах, которые у меня есть, без установленных часовых поясов :(

lukinhaspm 10 февр. 2018

@lukinhaspm это не вопрос сервера, это просто вопрос правильного представления метки времени в HeidiSQL. UNIX TIMESTAMP всегда должен быть в секундах после 1970-01-01 00:00:00 UTC.

Вы можете представить такую временную метку строго в формате UTC, что нормально, или в определенном (в основном своем) часовом поясе. Для этого нужен действительный часовой пояс на дате отметки времени, а не на фактической дате.
Похоже, что HeidiSQL берет актуальную дату. Я еще не заглядывал в его код, так что это всего лишь предположение.

mpaland 11 февр. 2018

👍1

@mpaland Понятно и согласен!

lukinhaspm 15 февр. 2018

Я исследовал это немного дальше. К сожалению, решение кажется непростым.
Проблема в том, что во всем мире действуют сложные правила перехода на летнее время (DST) и, что еще хуже, их постоянно меняющаяся, непостоянная форма.
Чтобы скорректировать летнее время по местному времени для метки времени определенной эпохи, необходимо знать точное правило летнего времени, которое применялось локально во время метки времени.
Библиотеке преобразования необходимо отслеживать все изменения правил перехода на летнее время в каждой стране за эти годы, чтобы рассчитать смещение для любой точки в прошлом.
Windows полностью игнорирует эту проблему и всегда выполняет преобразование в соответствии с правилом _actual_ DST во время преобразования.
Чтобы сделать это правильно, необходимо использовать одну из действительно продвинутых библиотек часовых поясов / летнего времени в сети.

mpaland 23 июл. 2018

Хотя большая часть того, что @mpaland заявил о необходимости знать правило перехода на летнее время, применяемое при создании метки времени, технически верно (например, если мы откажемся от перехода на летнее время, все моменты, записанные, когда оно было активным, "сместятся" на относительный недневной свет. экономия времени), по-прежнему можно использовать текущие правила летнего времени для правильного отображения времени для метки времени.

1584975600 и 1585576800 оба 16:00 в Европе / Мадриде, но heidisql неверно представляет один из них (в зависимости от того, используется ли мы летнее время или нет)

Можно было бы правильно отобразить эти случаи, не создавая больших хлопот, просто проверив, должно ли полученное время быть в летнем времени или нет, и применив правильное смещение.

Несмотря на то, что это не идеальное решение, я бы сказал, что оно, вероятно, охватывает большинство случаев использования, а крайние случаи, вероятно, будут легко обнаружены, в любом случае это скорее небольшая помощь для разработчиков, чем проверка надежного дисплея конечного пользователя.