Временные метки: iso8601 vs unix timestamp

Question

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

Для обслуживания я пишу записи базы данных создаются и хранятся как на мобильных устройствах, так и на нашем веб-сайте и должны синхронизироваться в обоих направлениях. В настоящее время мы ориентируемся на Android и iOS, которые используют SQLite как реляционную базу данных. Серверная сторона реализована в Python с использованием Django с MySQL, но другие решения могут заменить это в будущем.

Синхронизация будет реализована в соответствии с идеями, изложенными в этом ответе SO: https://stackoverflow.com/a/5052208/2076094. Для синхронизации мы будем использовать временную метку, установленную только сервером и синхронизированную с клиентами, last_synced_date и отметки времени для создания и обновления объекта. Поскольку объекты ссылаются на то, что пользователь сделал в определенное время, они также имеют информацию о временной отметке.

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

• Unix-время
• ISO8601

Это article, который был на Hacker News (дважды) предлагает использовать UNIX время и представляет довольно хороший аргумент. Дискуссия о HN, как и следовало ожидать, немного расходится вокруг двух пунктов, описанных выше, а затем и некоторых.

До сих пор мой вывод состоит в том, что временные метки Unix-времени легче обрабатывать, но, похоже, это не обычный способ работы в Django. Почти каждый пример кода, который я нашел, из учебника Django для многих других сайтов, использует DateTimeField в файле models.py, который сопоставляется с каким-то полем даты в SQL, точными терминами в зависимости от используемой базы данных.

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

Другое дело, что вы можете легко попасть в проблему, используя «умные» поля «Дата» или «Временная метка» в базе данных (и во время разбора). Есть много вопросов о SO относительно магии времени, которая закручивает вещи. Мой лимит связи достигнут, поэтому я не могу опубликовать его, но вы легко найдете его;)

Мы могли бы использовать упрощенный формат, который не включает информацию о часовом поясе и всегда использовать UTC. Мы будем использовать UTC только в любом случае, но, похоже, если вы используете ISO8601, вы можете использовать формат, который универсально понятен и недвусмыслен. Unix-время всегда в UTC, так что вам никогда не придется беспокоиться об этом.

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

Кажется, что, написав вещи, у меня есть уже мой ответ;) В любом случае, я хотел бы знать, что думают другие и что вы делаете в своих проектах. Пожалуйста, дайте краткое описание вашего варианта использования, чтобы другие могли лучше классифицировать ваш ввод.

Спасибо!

Answer 1

спасибо за этот замечательный вопрос, который вы положили на стол. Очень сложно найти информацию о временных типах данных или временных стандартах/форматах, что бы это ни называлось. В течение последних нескольких дней я сам боролся за выбор правильного формата времени. Как вы, я кодирую как на мобильных устройствах, так и на веб-сервере (не говоря уже о том, что также будет приложение для настольных компьютеров). Мои технические навыки довольно эмпирические, мое фоновое исследование - это искусство, но я часто работаю с кодированием. И главный вопрос, который я задавал себе, заключался в том, «как я могу получить беспрепятственный опыт между мобильным устройством, веб-сервером (API или тем, что вы хотите называть) и настольным приложением? Как вы можете быть последовательным, когда произошло событие и как убедиться, что представление этого момента одинаково на разных уровнях этой созвездии программного обеспечения?

Как вы знаете, кодирование с помощью мобильных устройств подразумевает, что вы используете базы данных SQLite, а веб-приложения в основном подразумевают MySQL. глубоко разочарован, узнав, что одна из самых больших головных болей, которые я когда-либо мог себе представить, - это перейти от одного стола к другому со временем. Что выбрать? DateTime? Timestamp? О, черт возьми, SQLite не имеет встроенного времени ... Unix время? Хорошо, нет проблем, конечно, MySQL не использует UNIX-время в качестве стандарта ... Было бы слишком просто ...

Что я узнал ... Если вы хотите разместить данные на временной шкале и сказать, что это точка временной шкалы, что произошло это событие, используйте временные метки (будь то стиль UNIX или MySQL, также известный как ISO8601). Чтение для человека - это просто деталь для меня. Никто не должен читать таблицы базы данных, компьютеры, и вы говорите компьютеру обрабатывать данные, чтобы люди могли понять. Но тогда вопрос «какой часовой пояс?» выскочил ... Ну ... это отстой ... Но эй, выкопаешь паутину для ответов.

Сам я удивлен, что MySQL не является пользователем UNIX-времени, я думаю, что это самое стандартное и последовательное время, которое у вас может быть.

Я действительно думаю, что документация по этим вопросам более светлая ... Я сейчас рассматриваю возможность написания статьи о том, как обрабатывать время с MySQL и SQLite. Я потратил 3 дня на этот вопрос, пытаясь понять, как сделать его чистым и простым. Мой вывод, с имеющейся документации, вы просто не можете ...: PI я, наверное, неправильно ... В любом случае, посмотрите на это видео, показывая борьбу манипуляции с данными времени на MySQL: http://www.youtube.com/watch?v=fp-etlirjbo

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

Приветствия,

Бен