Timestamp: iso8601 vs unix timestamp

Question

So che questa è una domanda abbastanza comune, ma non mi sento come se le risposte che ho trovato risolvessero davvero il problema. Illustrerò il mio caso d'uso specifico e presenterò riepiloghi alle informazioni provenienti da altre risposte SO e sul web.

Per il servizio che sto scrivendo, le voci del database vengono create e archiviate sia sui dispositivi mobili che sul nostro sito Web e devono essere sincronizzate in entrambi i modi. Al momento stiamo prendendo di mira Android e iOS, che utilizzano entrambi sqlite come database relazionale. Il lato server è implementato in Python usando Django con MySQL, ma altre soluzioni potrebbero sostituirlo in futuro.

La sincronizzazione verrà implementata seguendo le idee descritte in questa risposta SO: https://stackoverflow.com/a/5052208/2076094. Per la sincronizzazione utilizzeremo un timestamp impostato solo dal server e sincronizzato con i client, l'ultimo_sincronizzato_data e il timestamp per la creazione e l'aggiornamento dell'oggetto. Poiché gli oggetti si riferiscono a qualcosa che l'utente ha fatto in determinati momenti, hanno anche informazioni sull'orario.

La mia domanda riguarda solo la rappresentazione interna del tempo utilizzato per questi timestamp. La rappresentazione utente nell'interfaccia utente è una versione localizzata e formattata della rappresentazione interna. Ci sono un certo numero di modi diversi sia nei linguaggi di implementazione che nei diversi database usati per rappresentare i timestamp. Dopo un bel po 'di ricerche sembrano esserci solo a soluzioni valide sinistra:

• Unix-tempo
• ISO8601

Questo article che era su Hacker News (due volte) suggerisce di usare il tempo UNIX e presenta una buona argomentazione. La discussione su HN, come è prevedibile, diverge un po 'attorno ai due punti sopra delineati e poi alcuni.

La mia conlusione finora è che i timestamp di Unix-time sono più facili da gestire, ma non sembrano essere il modo comune per andare a Django. Quasi tutti gli esempi di codice che ho trovato, dal tutorial di Django a molti altri siti, utilizzano un DateTimeField nel model.py che viene mappato su una sorta di campo data in SQL, i termini esatti che dipendono dal database utilizzato.

Lo svantaggio di utilizzare le date ISO8601 per la trasmissione e l'archiviazione è che devono essere analizzati per creare il tipo di data della rispettiva lingua di implementazione. Non è difficile, ma piuttosto fastidioso. Per ogni singola lingua che stiamo usando, hai bisogno di una (piccola) libreria o almeno di un codice più lungo di quello che spereresti. Non è molto carino, crea dipendenze ed è probabilmente leggermente più lento. I timestamp di Unix-time non hanno questo problema in nessuna lingua che conosco.

L'altra cosa è che puoi facilmente metterti nei guai usando i campi "smart" Data o Timestamp nel database (e durante l'analisi). Ci sono molte domande su SO riguardo alla magia del tempo che rovina tutto. Il limite del mio link è stato raggiunto, quindi non posso postarne alcuno, ma ne troverai facilmente;)

Potremmo usare un formato semplificato che non include le informazioni sul fuso orario e utilizzare sempre UTC. Useremo comunque l'UTC, ma sembra che se si usi ISO8601, si potrebbe anche usare un formato che sia universalmente compreso e non ambiguo. Unix-time è sempre in UTC, quindi non devi mai preoccuparti di questo.

Naturalmente ISO8601 ha il vantaggio di essere leggibile dall'uomo quando si guarda il database non elaborato e non dovrò riscrivere un paio di righe di codice poco prima del 2038, ma ciò non sembra compensare aspetti negativi.

Sembra che scrivendo le cose ho già la mia risposta;) Comunque, mi piacerebbe sapere cosa pensano gli altri e cosa fai nei tuoi progetti. Si prega di fornire una breve descrizione del proprio caso d'uso, in modo che altri possano classificare meglio il proprio input.

Grazie!

Answer 1

grazie per questa grande domanda che hai messo sul tavolo. È davvero difficile trovare informazioni su tipi di dati temporali o standard/formati temporali, qualunque sia il nome. Negli ultimi giorni ho lottato per scegliere il formato temporale giusto. Come te, sto codificando in entrambi i dispositivi mobili e in un server web (senza contare che ci sarà anche un'applicazione desktop). Le mie capacità tecniche sono piuttosto empiriche, il mio studio di base è arte, ma lavoro spesso con la programmazione. E la domanda principale che mi stavo ponendo era "come posso avere un'esperienza perfetta tra il dispositivo mobile, il server web (API o qualsiasi altra cosa tu voglia chiamare) e l'applicazione desktop? Come puoi essere coerente quando si è verificato un evento? e come fare in modo che la rappresentazione di questo istante sia la stessa nei diversi livelli di questa costellazione di software?

Come si può sapere, la codifica con dispositivi mobili implica l'utilizzo di database SQLite e le applicazioni Web implicano in gran parte MySQL. profondamente deluso di sapere che uno dei più grossi mal di testa che potessi immaginare era passare da un tavolo all'altro con i dati del tempo. Cosa scegliere? DateTime? Timestamp? Oh Dio, SQLite non ha un tipo di dati temporali incorporato ... Tempo Unix? Ok, nessun problema, ovviamente MySQL non usa il tempo UNIX come standard ... Sarebbe troppo semplice ...

Quello che ho imparato è ... Se si desidera posizionare i dati su una timeline e dire che questo è il punto della linea temporale che questo evento è accaduto, utilizzare i timestamp (sia esso UNIX o stile MySQL, ovvero ISO8601). Human readable è solo un dettaglio per me. Nessun essere umano dovrebbe leggere le tabelle del database, i computer lo fanno e tu devi dire al computer di gestire i dati affinché gli umani possano capire. Ma poi la domanda "qual è il fuso orario?" è saltato fuori ... beh ... fa schifo ... ma hey, scaverà il web per le risposte.

Io stesso sono sorpreso che MySQL non utilizzi il tempo UNIX, penso che questo sia il tempo più standard e coerente possibile.

Penso davvero che la documentazione su questo argomento sia più leggera della luce ... Ora sto pensando di scrivere un articolo su come gestire il tempo con MySQL e SQLite. Ho perso davvero 3 giorni su questo argomento, cercando di capire come renderlo pulito e semplice. La mia conclusione, con la documentazione disponibile non puoi proprio ...: PI sono probabilmente sbagliato ... In ogni modo, date un'occhiata a questo video che mostra le lotte di trattamento effettuato con i dati in tempo su MySQL: http://www.youtube.com/watch?v=fp-etlirjbo

Grazie per la pubblicazione di questa domanda, è stato abbastanza illuminante per me.

Cheers,

Ben