DateTime, the Epoch and DocumentDb

Question

Così ho letto questo blog molto interessante sul lavoro con datetime in Azure DocumentDb. Il problema è che, al momento, Azure DocumentDb non supporta la ricerca di intervalli sui campi datetime. Il motivo è che DocumentDb è basato su json e che non ha un tipo data/ora, quindi solitamente lo inserisce in una stringa di formato datetime xml.

(ovviamente Mongo non ha questo problema, è BSON formato aggiunge il tipo datetime (tra gli altri))

Comunque, l'articolo descrive la memorizzazione datetime in json in un'epoca (unix) tempo, essenzialmente memorizzazione della datetime come una quantità di secondi dal 01-01-1970. Un problema di epoca è che non tiene conto dei secondi bisestili, ma per ora posso conviverci.

La mia domanda è che mi piacerebbe anche memorizzare le date di nascita in tale formato. Ora potrei semplicemente prendere 01-01-1900 come data di inizio e memorizzare la quantità di giorni da quella data in un int. Mentre sono abbastanza sicuro che ciò funzionerebbe bene, sembra che l'epoca sia un concetto ben consolidato, ma quello dei compleanni è come se stessi costruendo le mie convenzioni, il che è una cosa che generalmente preferisco evitare.

Esiste uno standard stabilito per la standardizzazione della memorizzazione della data come numero? Quale data dovrebbe essere la data di riferimento?

Answer 1

Prima di tutto, un aggiornamento: DocumentDB ora supporta indici di intervallo su stringhe e numeri. Devi impostare gli indici correttamente affinché funzioni.

Ora, per darvi una raccomandazione. Ho archiviato con successo i timestamp ISO-8601 come stringhe. Questo è il formato predefinito utilizzato da DocumentDB SDK per gestire DateTime in modo che sia meno utile della conversione in un numero intero.

Le stringhe di data/ora ISO-8601 hanno diverse proprietà che corrispondono alle vostre esigenze.

1. L'ordinamento alfanumerico è cronologico in modo che funziona perfettamente come previsto con clausole di query utilizzando>, <,> =, < =, e TRA supponendo di avere un indice di gamma appropriata di precisione (-1 per intera precisione);
2. Sono leggibili dall'uomo, quindi se si sta navigando in una tabella, i dati hanno un senso;
3. Questo formato consente la specifica di data/ora di granularità inferiore. Ad esempio, dovresti dire "2015-03" per indicare il mese di marzo o "2015-03-24" per indicare il 24 marzo 2015. Puoi quindi inviare una query con questo filtro "startedOn> = 2015-03- 24 AND startedOn < 2015-03-25 "per trovare tutto ciò che è iniziato il 24 marzo 2015. Funziona anche quando startedOn è memorizzato come una stringa ISO-8601 completa come" 2015-03-24T12: 34: 56.789Z "a causa di la natura del confronto delle stringhe.

Ho scritto su questo approccio here.

Answer 2

Nella mia esperienza non ho riscontrato uno standard più "consolidato" rispetto all'epoca UNIX. Ciò detto, alcuni aspetti architettonici/tecnologici dell'archiviazione del tempo sono stati discussi in precedenza: Timestamps and time zone conversions in Java and MySQL

Vorrei chiedere perché si rischia di utilizzare la propria convenzione? È un rischio perché: se un po 'di tempo vorresti aggiungere ore al tuo conteggio del giorno, magari essere in grado di ordinare le persone in base a quando esattamente durante il giorno in cui sono nate. La domanda può essere estesa a: cosa succede se ad un certo punto si desidera misurare più momenti generici o più a grana fine; dovresti tradurre la tua intera funzionalità, possibilmente attraverso molti livelli della tua applicazione, in un meccanismo/convenzione più generico. Un'altra domanda (simile) sarebbe: misurerai sempre eventi una volta nella vita per le persone nel tuo database o saranno in grado di creare nuovi eventi illimitati? Man mano che aumenta il numero di eventi aumenta anche il rischio di collisione e il conteggio del giorno non è adatto come un timestamp misurato in secondi o millisecondi.

Il tempo UNIX è praticamente onnipresente, si dispone di metodi speciali per ottenerlo nella maggior parte dei linguaggi di programmazione.L'architettura cronometraggio i sosterrà sempre & attuare nei miei progetti è questo: http://www.currentmillis.com/tutorials/system-currentTimeMillis.html

Come affermato anche nella mia risposta alla domanda linkato sopra, i vantaggi di memorizzazione tempo millisecondi da UNIX epoca sono:

• architettura chiarezza: lato server funziona con UTC, lato client mostra il tempo attraverso il suo fuso orario locale
• banca dati semplicità: memorizzare un numero (millisecondi) piuttosto che strutture di dati complesse come DateTimes
• efficienza di programmazione: nella maggior parte dei linguaggi di programmazione che avete data/ora oggetti in grado di assumere millisecondi dall'Epoca quando costruito (che consente la conversione automatica al fuso orario sul lato client)

---

Perché lei ha citato C#, DateTime.MinValue viene in mente. Questo sarebbe fondamentalmente l'anno 0 (mezzanotte, 1 gennaio).

Inoltre, questo sarebbe un codice che permetterà di ottenere i millisecondi dalla data di riferimento prescelto (qualunque esso sia) ma nota che 1900 è ancora diverso da quello 'epoca' di NET (DateTime.MinValue)

Answer 3

The answer by Teo è corretto, tranne che ho il sospetto in termini di "ben consolidato", i miliardi di fogli di lavoro Microsoft Excel, LibreOffice e Lotus 1-2-3 con la loro epoca possono superare di gran lunga l'utilizzo di Unix Time. O il miliardo di dispositivi e computer Apple Cocoa con la loro epoca.

Si noti che uno couple dozen different epochs è stato utilizzato da vari ambienti di computer. Il tempo Unix è lontano dall'essere solo o addirittura dominante.

Si noti inoltre che non esiste esattamente il valore Unix time. Le varianti includono l'utilizzo di secondi interi, millisecondi, microsecondi o nanosecondi.

Se possibile, utilizzare un tipo di dati esperto di data e ora. Assicurati di studiare il doc e sperimentare per capire chiaramente che è un comportamento.

Dove non è possibile utilizzare un tipo di dati, fallback per l'utilizzo di una stringa nei vari formati ISO 8601. Alcuni di questi formati standard sono alfabeticamente cronologici nell'ordinamento, in particolare per i valori di sola data: AAAA-MM-GG.

I secondi di salto vengono ignorati in ogni sistema di tracciamento di data e ora che conosco. Il loro scopo è quello di rendere il nostro orologio orario con calendario, quindi per scopi commerciali il Leap Second è in un certo senso destinato a essere ignorato.

Le ore di lavoro sono sorprendentemente difficili e sfavorevoli. Cerca StackOverflow per scoprire i numerosi problemi. Cerca di evitare di far rotolare le tue soluzioni. In particolare per C#, guarda lo Noda Time library.