Memorizzazione di un giorno di calendario nel database sqlite

Question

Devo archiviare gli articoli con una data di calendario (solo il giorno, senza ora) in un database sqlite. Qual è il modo migliore per rappresentare la data nella colonna? I giorni giuliani e i secondi unix vengono in mente come alternative ragionevoli. Se vado con un'unità diversa dai giorni a che ora dovrebbe essere?

Aggiornamento: sono a conoscenza di ISO8601 e in realtà l'ho usato per memorizzare la data come stringa nel formato AAAA-MM-GG per il prototipo. Ma per varie aritmetiche devo convertirlo internamente in un numero, quindi preferirei memorizzare un numero e convertirlo in stringa per la visualizzazione. In quali unità dovrebbe trovarsi questo numero, con quale origine e se le unità sono più precise dei giorni a che ora del giorno dovrebbero essere utilizzate?

Answer 1

Se si prevede di consegnare la data a uno strumento o una libreria esterni, è necessario utilizzare il formato previsto. Il tempo di Unix sembra essere la lingua franca dell'orografia digitale, quindi è un buon default se le circostanze esterne non fanno la scelta giusta per te.

ISO 8601 potrebbe essere interessante.

Modifica:

  

Ma per varie aritmetiche devo convertirlo in un numero internamente, quindi preferirei memorizzare un numero e convertirlo in stringa per la visualizzazione.

Ah, ha senso. Se il tuo ambiente (.NET? Python? C ++?) Ha strumenti di gestione del tempo, sarebbe meglio usare la loro unità nativa e epoca. Non c'è motivo di riscrivere tutte quelle funzioni di manipolazione della data; sono più complicati di quello che sembrano. Altrimenti, userei i giorni nel calendario locale (gregoriano?) Da un'epoca ragionevole per la tua applicazione. Sii generoso, non vuoi un bug Y2K inverso quando improvvisamente devi gestire una data prima di quanto ti aspettassi.

L'ora del giorno è interamente una questione di gusti. La mezzanotte sembra la scelta più pulita (tutti zeri nelle ore, minuti, secondi campi), ma dal momento che non raggiunge mai l'utente non ha implicazioni pratiche. In effetti sarebbe un buon posto per un uovo di Pasqua.

Answer 2

Se vuoi coprire le tue basi assicurati di memorizzare la data in utc e scegli uno standard iso. Questo approccio richiede uno sforzo minimo e proteggerà il codice dai futuri mal di testa Interop. Sono d'accordo con @skymt ISO 8601 è una buona scelta.

Answer 3

Se stai usando C ++, vale la pena dare un'occhiata a boost :: date_time.

Answer 4

" Migliore " dipende quasi interamente da dove provengono le date (oggetti NSDate, alcuni feed XML) e da come vengono manipolate (semplicemente archiviate così come sono invece di fare qualche aritmetica come "giorni fino a").

Non lo sto necessariamente raccomandando, ma ho scritto un'app che doveva anche memorizzare la data, ma non l'ora, in un DB SQLite. Inizialmente ho usato due colonne, Month e Day, in cui Month è stato definito come il numero di mesi dal gennaio 2000. Avevo bisogno di imporre una riga per data, quindi ho definito un indice UNICO su quelle due colonne e ha girato per rendere gli aggiornamenti orribilmente lenti.

Per il mio secondo tentativo, ho usato uno schema simile ma ho codificato la data in un numero, usando i 5 bit inferiori per il giorno e i bit superiori rimanenti per il mese (di nuovo, dal gennaio 2000). Le funzioni di conversione erano:

Date = (Month << 5) | Day
Month = Date >> 5
Day = 0x1F & Date

Questo schema conserva l'ordine numerico delle date e semplifica la suddivisione in componenti. Aveva senso per la mia app, perché stavo archiviando i dati in blocchi mensili. Se, data una Data, desideri trovare la Data successiva, questo schema potrebbe non essere il migliore, poiché la Data + 1 potrebbe non essere una data valida.