Я знаю, что это довольно распространенный вопрос, но я не чувствую, что ответы, которые я нашел, действительно решают проблему. Я расскажу о своем конкретном случае использования и приведу резюме к информации из других ответов SO и в Интернете.
Для службы, которую я пишу, записи базы данных создаются и хранятся как на мобильных устройствах, так и на нашем веб-сайте, и их необходимо синхронизировать в обоих направлениях. В настоящее время мы ориентируемся на Android и iOS, которые используют SQLite как реляционную базу данных. Серверная часть реализована в Python с использованием Django с MySQL, но другие решения могут заменить это в будущем.
Синхронизация будет реализована в соответствии с идеями, изложенными в этом SO-ответе: qaru.site/info/25323/.... Для синхронизации мы будем использовать временную метку, установленную только сервером и синхронизированную с клиентами, last_synced_date и отметки времени для создания и обновления объекта. Поскольку объекты ссылаются на то, что пользователь сделал в определенное время, они также имеют информацию о отметке времени.
Мой вопрос касается только внутреннего представления времени, используемого для этих временных меток. Представление пользователя в пользовательском интерфейсе представляет собой локализованную и отформатированную версию внутреннего представления. Существует множество различных способов как на языках реализации, так и в разных базах данных, используемых для представления временных меток. После довольно немного исследований, похоже, остались только правильные решения:
- Unix времени
- ISO8601
До сих пор мой вывод состоит в том, что временные метки Unix-времени легче обрабатывать, но, похоже, это не обычный способ работы в Django. Почти каждый пример кода, который я нашел, из учебника Django для многих других сайтов, использует DateTimeField в файле models.py, который сопоставляется с каким-то полем даты в SQL, точными терминами в зависимости от используемой базы данных.
Недостатком использования дат ISO8601 для передачи и хранения является то, что они должны быть проанализированы для создания соответствующего типа даты. Это не сложно, а раздражительно. Для каждого отдельного языка, который мы используем, вам нужна либо небольшая библиотека, либо, по крайней мере, больше кода, чем вы могли бы надеяться. Это не очень красиво, создает зависимости и, вероятно, немного медленнее. Временные метки Unix-времени не имеют этой проблемы в любом значении, которое я знаю.
Другое дело, что вы можете легко попасть в проблему, используя "умные" поля "Дата" или "Временная метка" в базе данных (и во время разбора). Есть много вопросов о SO относительно магии времени, которая закручивает вещи. Мой лимит связи достигнут, поэтому я не могу публиковать его, но вы легко найдете некоторые;)
Мы могли бы использовать упрощенный формат, который не включает информацию о часовом поясе и всегда использовать UTC. Мы будем использовать UTC только в любом случае, но, похоже, если вы используете ISO8601, вы можете использовать формат, который универсально понятен и недвусмыслен. Unix-время всегда в UTC, поэтому вам никогда не придется беспокоиться об этом.
Конечно, ISO8601 имеет то преимущество, что он читается человеком, когда вы смотрите на необработанную базу данных, и мне не придется переписывать пару строк кода незадолго до 2038 года, но это, похоже, не компенсирует недостатки.
Кажется, что, написав вещи, я действительно получил свой ответ уже;) В любом случае, я хотел бы знать, что думают другие и что вы делаете в своих собственных проектах. Пожалуйста, дайте краткое описание вашего варианта использования, чтобы другие могли лучше классифицировать ваш ввод.
Спасибо!
