DateTime, die Epoche und DocumentDb

Question

Also lese ich diesen sehr interessanten Blog über die Arbeit mit datetime in Azure DocumentDb. Das Problem dabei ist, dass Azure DocumentDb momentan keine Bereichssuche in Datetime-Feldern unterstützt. Der Grund dafür ist, dass DocumentDb auf json basiert und keinen Datetime-Typ hat. Daher wird es normalerweise in eine Zeichenfolge vom XML-Datetime-Format eingefügt.

(offensichtlich Mongo diese Frage nicht hat, es ist BSON Format des Datetime-Typ (unter anderem) fügt)

Wie dem auch sei

, beschreibt der Artikel die Datetime in json in einer Epoche (Unix) Zeit Speicherung Speicherung im Wesentlichen die datetime als Anzahl der Sekunden seit dem 01.01.1970. Ein Problem der Epoche ist, dass es keine Schaltsekunden berücksichtigt, aber damit kann ich jetzt leben.

Meine Frage ist, dass ich auch Geburtsdaten in einem solchen Format speichern möchte. Jetzt könnte ich 01.01.1900 als Startdatum nehmen und die Anzahl der Tage seit diesem Datum in einem Int speichern. Ich bin mir ziemlich sicher, dass das gut funktionieren würde, aber es fühlt sich an, als sei die Epoche ein gut etabliertes Konzept, aber das für Geburtstage fühlt sich an, als würde ich meine eigenen Konventionen aufbauen, was ich im Allgemeinen gerne vermeide.

Gibt es einen Standard für die Standardisierung der Datumsspeicherung als Nummer? Welches Datum sollte das Basisdatum sein?

Answer 1

Zunächst ein Update: DocumentDB unterstützt nun Bereichsindizes für Strings und Zahlen. Sie müssen die Indizes korrekt einrichten, damit sie funktionieren.

Jetzt, um Ihnen eine Empfehlung zu geben. Ich habe erfolgreich ISO-8601-Zeitstempel als Zeichenfolgen gespeichert. Dies ist das Standardformat, das vom DocumentDB-SDK für die Verarbeitung von DateTime verwendet wird, sodass es weniger Arbeit erfordert als die Konvertierung in eine ganze Zahl.

ISO-8601 Datum/Uhrzeit-Zeichenfolgen haben mehrere Eigenschaften, die Ihren Anforderungen entsprechen.

1. Die alphanumerische Sortierreihenfolge ist chronologisch, so dass es perfekt wie erwartet mit Abfrageklauseln arbeitet mit>, <,> =, < = und BETWEEN vorausgesetzt, Sie eine Reihe Index entsprechender Präzision haben (-1 für volle Präzision);
2. Sie sind menschlich lesbar, wenn Sie also eine Tabelle durchsuchen, machen die Daten Sinn;
3. Dieses Format ermöglicht die Angabe von Datum/Uhrzeit mit geringerer Granularität. Sie sollten beispielsweise "2015-03" für den Monat März oder "2015-03-24" für den 24. März 2015 angeben. Sie können dann eine Abfrage mit diesem Filter erstellen "starteOn> = 2015-03- 24 AND startOn < 2015-03-25 "alles zu finden, was am 24. März 2015 gestartet wurde. Dies funktioniert auch, wenn starteOn als vollständige ISO-8601-Zeichenfolge wie" 2015-03-24T12: 34: 56.789Z "gespeichert ist die Art des Stringvergleichs.

Ich habe über diesen Ansatz here geschrieben.

Answer 2

Meiner Erfahrung nach habe ich keinen "etablierteren" Standard als die UNIX-Epoche kennengelernt. Einige architektonische/technologische Aspekte der Zeitspeicherung wurden bereits zuvor besprochen: Timestamps and time zone conversions in Java and MySQL

Ich würde fragen, warum riskieren Sie mit Ihrer eigenen Konvention? Es ist ein Risiko, weil: Was, wenn einige Zeit Sie Stunden zu Ihrem Tag zählen möchten, vielleicht in der Lage sein, Menschen basierend auf wann genau während des Tages, an dem sie geboren wurden, zu bestellen. Die Frage kann erweitert werden auf: Was, wenn Sie irgendwann mehr generische oder feinkörnigere Momente messen möchten; Sie müssten Ihr gesamtes Feature, möglicherweise in vielen Schichten Ihrer Anwendung, in einen allgemeineren Mechanismus/Konvention übersetzen. Eine andere (ähnliche) Frage wäre: Werden Sie immer einmalige Ereignisse für die Personen in Ihrer Datenbank messen oder können sie neue, unbegrenzte Ereignisse erstellen? Wenn die Anzahl der Ereignisse zunimmt, erhöht sich auch das Kollisionsrisiko und eine Tageszählung wäre nicht so geeignet wie ein Zeitstempel, der in Sekunden oder Millisekunden gemessen wird.

UNIX-Zeit ist grundsätzlich allgegenwärtig, Sie haben spezielle Methoden, um es in den meisten Programmiersprachen zu bekommen.Die Zeitnehmung Architektur i immer & unterstützt in meiner Projekte implementieren, ist dies: http://www.currentmillis.com/tutorials/system-currentTimeMillis.html

Wie auch in meiner Antwort auf die Frage oben verlinkten angegeben, die Vorteile der Zeit als Millisekunden seit der UNIX-Speicherung Epoche ist:

• Architektur Klarheit: Server-Seite arbeitet mit UTC, Client-Seite zeigt die Zeit durch die lokale Zeitzone
• Datenbank Einfachheit: Sie speichern eine Nummer (Millisekunden), anstatt komplexe Datenstrukturen wie Datetime
• Programmierung Effizienz: in den meisten Programmiersprachen Sie Datum haben/Zeit-Objekte Millisekunden seit der Epoche des Nehmens fähig, wenn gebaut (die für die automatische Konvertierung erlaubt zu clientseitige Zeitzone)

---

Weil Sie C# erwähnt, kommt DateTime.MinValue in den Sinn. Dies wäre im Grunde das Jahr 0 (Mitternacht, 1. Januar).

Auch wäre dies ein Code sein, mit dem Sie die millis seit dem gewählten Stichtag zu erhalten erlauben würde (was immer es ist), aber beachten Sie, dass 1900 noch anders ist als .NET ist ‚Epoche‘ (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 ist korrekt, außer dass ich vermute, in Bezug auf "gut etabliert", die Milliarden von Microsoft Excel, LibreOffice und Lotus 1-2-3 Tabellenkalkulation mit ihrer eigenen Epoche können Unix Time-Nutzung weit übertreffen. Oder die Milliarden von Apple Cocoa Geräten und Computern mit ihrer eigenen Epoche.

Beachten Sie, dass in verschiedenen Computerumgebungen couple dozen different epochs verwendet wurden. Unix-Zeit ist bei weitem nicht allein oder gar dominant.

Auch beachten Sie, dass es so etwas wie Unix time nicht genau gibt. Variationen umfassen die Verwendung ganzer Sekunden, Millisekunden, Mikrosekunden oder Nanosekunden.

Verwenden Sie nach Möglichkeit einen Datum/Uhrzeit-Datentyp. Achten Sie darauf, das Dokument zu studieren und zu experimentieren, um sein Verhalten klar zu verstehen.

Wenn es nicht möglich ist, einen Datentyp zu verwenden, kann auf eine Zeichenfolge in den verschiedenen Formaten ISO 8601 zurückgegriffen werden. Einige dieser Standardformate sind in der Sortierung alphabetisch chronologisch angeordnet, insbesondere für Datumswerte: JJJJ-MM-TT.

Schaltsekunden werden in jedem mir bekannten Datum-Zeit-Verfolgungssystem ignoriert. Ihr Zweck ist, unsere stündliche Uhr mit Kalender zu machen, so dass für geschäftliche Zwecke die Leap Second in gewissem Sinne gemeint ist, ignoriert zu werden.

Date-Time-Arbeit ist überraschend schwierig und rutschig Geschäft. Durchsuchen Sie StackOverflow, um die vielen Probleme zu entdecken. Versuchen Sie zu vermeiden, eigene Lösungen zu rollen. Sehen Sie sich insbesondere für C# die Noda Time library an.