DateTime, Epoch и DocumentDb

Question

Итак, я прочитал этот очень интересный блог о работе с datetime in Azure DocumentDb. Проблема заключается в том, что в настоящее время Azure DocumentDb не поддерживает поиск диапазона в полях datetime. Причиной этого является то, что DocumentDb основан на json и не имеет типа datetime, поэтому обычно он помещается в строку формата datetime в формате xml.

(очевидно Монго не имеет эту проблему, это BSON формат добавляет типа DATETIME (среди прочих))

Во всяком случае, в статье описывается хранение DateTime в формате JSON в эпохе (Unix) время, по сути хранения datetime как количество секунд с 01-01-1970. Одна из проблем эпохи заключается в том, что она не учитывает секунды прыжка, но я могу жить с этим пока.

Мой вопрос в том, что я также хотел бы хранить даты рождения в таком формате. Теперь я могу просто взять 01-01-1900 в качестве даты начала и сохранить количество дней с этой даты в int. Хотя я уверен, что это будет хорошо работать, похоже, что эпоха - это хорошо зарекомендовавшая себя концепция, но в дни рождения мне кажется, что я строю свои собственные соглашения, чего я обычно избегаю.

Есть ли установленный стандарт для стандартизации хранения даты в виде числа? Какая дата должна быть базовой датой?

Answer 1

Прежде всего, обновление: DocumentDB теперь поддерживает индексы диапазонов как для строк, так и для чисел. Вы должны правильно настроить индексы для его работы.

Теперь, чтобы дать вам рекомендацию. Мне удалось сохранить метки времени ISO-8601 как строки. Это формат по умолчанию, используемый DocumentDB SDK для обработки DateTime, поэтому он меньше работает, чем конвертирование в целое.

Строки даты и времени ISO-8601 имеют несколько свойств, соответствующих вашим потребностям.

1. альфа-числовой порядок сортировки хронологический, так что работает отлично, как и ожидалось с пунктами запроса с использованием>, <,> =, = < и BETWEEN если у вас есть индекс диапазона соответствующей точности (-1 для полного точность);
2. Они читаются человеком, поэтому, если вы просматриваете таблицу, данные имеют смысл;
3. Этот формат позволяет специфицировать дату и время меньшей гранулярности. Например, вы должны сказать, что «2015-03» означает месяц марша, или «2015-03-24» означает 24 марта 2015 года. Затем вы можете отправить запрос с этим фильтром «startOn> = 2015-03- 24 И началOn < 2015-03-25 ", чтобы найти все, что началось 24 марта 2015 года. Это работает даже при запускеОн хранится как полная строка ISO-8601, например," 2015-03-24T12: 34: 56.789Z "из-за характер сравнения строк.

Я писал об этом подходе here.

Answer 2

По моему опыту, я не встречал более «установленного» стандарта, чем эпоха UNIX. При этом некоторые архитектурные/технологические аспекты хранения времени обсуждались ранее: Timestamps and time zone conversions in Java and MySQL

Я бы спросил, почему рискуешь использовать свою собственную конвенцию? Это риск, потому что: что, если какое-то время вы захотите добавить часы в свой день, возможно, чтобы иметь возможность заказывать людей, исходя из того, когда именно в течение дня они родились. Вопрос может быть продлен до: что, если в какой-то момент вы хотите измерить более общие или более мелкозернистые моменты; вам придется перевести всю вашу функцию, возможно, на многие уровни вашего приложения, на более общий механизм/соглашение. Другой (аналогичный) вопрос: будете ли вы всегда измерять события «один раз в жизни» для людей в вашей базе данных или они смогут создавать новые, неограниченные события? По мере увеличения количества событий увеличивается риск столкновения, и количество дней не будет таким подходящим, как отметка времени, измеренная в секундах или миллисекундах.

UNIX время в основном вездесущее, у вас есть специальные методы для его получения на большинстве языков программирования.Архитектура хронометража я всегда буду поддерживать & реализовывать в своих проектах заключается в следующем: http://www.currentmillis.com/tutorials/system-currentTimeMillis.html

Как также указано в моем ответе на вопрос, связанный выше, преимущества хранения времени в миллисекундах с момента UNIX эпоха являются: ясность

• архитектура: на стороне сервера работает с UTC, на стороне клиента показывает время через локальный часовой пояс
• базы данных простота: вы сохраняете число (миллисекунды), а не сложные структуры данных, как DateTimes
• эффективности программирования: в большинстве языков программирования вы имеют дату/время, объекты, способные принимать миллисекунды, поскольку Epoch когда построен (что позволяет автоматическое преобразование на стороне клиента часовой пояс)

---

Поскольку вы упомянули C#, DateTime.MinValue приходит на ум. Это будет в основном год 0 (полночь, 1 января).

Кроме того, это будет какой-то код, который позволит вам получить Миллисекунды выбранной даты (то, что это), но обратите внимание, что 1900 по-прежнему отличается от «эпохи» .NET (в DateTime.MinValue)

// Unix Epoch 
(DateTime.UtcNow - new DateTime (1970, 1, 1)).TotalMilliseconds 
// NTP Epoch 
(DateTime.UtcNow - new DateTime (1900, 1, 1)).TotalMilliseconds 

Answer 3

The answer by Teo является правильным, за исключением того, что я подозреваю, что с точки зрения того, что он «хорошо установлен», миллиарды таблиц Microsoft Excel, LibreOffice и Lotus 1-2-3 со своей собственной эпохой могут намного превышать количество использования Unix Time. Или миллиард Apple Cocoa устройств и компьютеров со своей собственной эпохой.

Знайте, что couple dozen different epochs был использован различными компьютерными средами. Время Unix далека от того, чтобы быть одиноким или даже доминирующим.

Также имейте в виду, что нет такой вещи, как Unix time. Вариации включают использование целых секунд, миллисекунд, микросекунд или наносекунды.

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

Если невозможно использовать тип данных, вернитесь к использованию строки в различных форматах ISO 8601. Некоторые из этих стандартных форматов сортируются по алфавиту в хронологическом порядке, особенно для значений только даты: YYYY-MM-DD.

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

Работа с датой на удивление сложная и скользкая. Найдите StackOverflow, чтобы обнаружить множество проблем. Старайтесь избегать опрокидывания собственных решений. Для C# в частности, посмотрите на Noda Time library.