Шестнадцатеричные числа, которые переводят в метки даты и времени - PullRequest
0 голосов
/ 10 мая 2019

У меня есть программа, которая хранит данные в базе данных SQLite в формате BLOB.

Часть данных, содержащихся в этом поле BLOB, представляет собой настройку даты и времени.

I 'Я пытаюсь понять формат этой даты и времени.

У меня нет доступа к реальному коду программы, я могу получить доступ только к базе данных SQLite, чтобы наблюдать за внесенными изменениями.

Например, если я установил в программе дату и время 2019-05-09-0500PM, шестнадцатеричный код выглядит следующим образом:

25 83 F5 03 A5 D6 80

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

Вот некоторые примеры настроек от меня, которые наблюдают за каждым изменением, которое я вносю в настройки даты и времени в программе:

Actual date and time    HEX code
2019-05-09 - 0400 PM    25 83 F5 03 6E E8 00
2019-05-09 - 0500 PM    25 83 F5 03 A5 D6 80
2020-05-09 - 1100 PM    25 83 F5 04 EF 6D 80
2019-05-10 - 1200 AM    25 83 F6 00 00 00 00
2019-05-10 - 0300 AM    25 83 F6 00 A4 CB 80
2019-05-10 - 0400 AM    25 83 F6 00 DB BA 00
2019-05-10 - 0400 PM    25 83 F6 03 6E E8 00
2019-06-09 - 0400 PM    25 84 14 03 6E E8 00
2020-05-09 - 0400 PM    25 85 63 03 6E E8 00

Кто-нибудь знает, в каком формате это и как я мог написатьмои собственные новые дата и время для этого поля BLOB?

Программа работает на Windows 10.

1 Ответ

1 голос
/ 10 мая 2019

0x2583F503A5D680 - 0x2583F5036EE800, с интервалом в 1 час, составляет 3600000. В часе 3600 секунд и, следовательно, 3600000 миллисекунд в час.Так, может быть, время отслеживания миллисекунд?

0x2583F6036EE800 - 0x2583F600DBBA00, с интервалом в 12 часов, составляет 43200000. Это также предполагает миллисекунды.

Но ... 0x2583F6036EE800 - 0x2583F5036EE800, с интервалом в 24 часа, это4294967296. Однако в течение 24 часов существует 86400000 миллисекунд.И 4294967296 не делится поровну на 24. Любопытно.Но ... 0x2583F6 - 0x2583F5 - это 1, а 0x036EE800 - 0x036EE800 - это, конечно, 0. Итак, похоже, что первые три байта отслеживают дату, а последние 4 подсчитывают количество миллисекунд с начала дня?0x03A5D680 - это 61200000, что также 3600000 * 17, так что это должно быть 5 вечера, если это так.Мы находимся на чем-то!

0x258563 - 0x2583F5, с интервалом в 1 год в 2019 и 2020 годах - 366. В 2020 году есть високосный год, поэтому имеет смысл, что это не 365, и помогает подтвердить эту теорию оформат.

0x2583F5 - 2458613 дней с момента 0 в этом формате.Это примерно 6735 лет.Дата начала счетчика Julian Day указана в 4713BC (или 4714BC в зависимости от того, какой календарь вы используете).Звучит как совпадение!

Из Википедии:

Юлианские даты выражаются в виде числа юлианских дней с добавлением десятичной дроби

Так выглядитнапример, это двоичная кодировка юлианской даты, которая использует миллисекунды для времени дня.Я понятия не имею, почему автор не использует значения REAL для хранения его в базе данных sqlite, тем более что это сделает его пригодным для использования с функциями даты и времени sqlite .Давайте использовать их для проверки:

sqlite> select julianday('2019-05-09 17:00:00');
2458613.208333333

Тот же номер дня, что и в BLOB-объекте.Итак, поехали.Формат:

  • 3 байта, чтобы записать юлианский день как бигендовское целое число.
  • 4 байта, чтобы записать миллисекунды с начала дня как бигендовское целое число.
...