(Dis) vantaggi di datetime rispetto a long in applicazioni globalmente utilizzate [closed]

1. Non penso che otterrai molto di più memorizzando tutto datetime s come long s. Ogni lingua che posso immaginare ha dei modi per convertire le date in altri formati (stringa, lungo) usa il formato preferito per il tuo database .

2. Memorizza le date in UTC . Penso che questo abbia senso per quasi tutte le applicazioni, dal momento che molte lingue e API hanno un modo per ottenere Now () in UTC. Inoltre, per la maggior parte dei dispositivi e dei browser è semplice calcolare l'offset del fuso orario. Quindi è semplice aggiunta per la visualizzazione dell'ora locale dell'utente. Ti risparmierai molto mal di testa lungo la strada.

Ci sono molte complicazioni nella conversione tra fusi orari, specialmente quando si considera l'ora legale e il pugno che non ha nemmeno un incremento di un'ora. Se stai utilizzando un database con un robusto supporto di TIMESTAMP , il passaggio allo storage intero non ti consente di accedere al gran numero di operazioni disponibili. Potrebbe sembrare una cosa opportuna da fare, ma dover implementare nuovamente tutte le conversioni nel proprio codice è ridondante e soggetto a errori. Perché reinventare una ruota già provata?

SQL92 definisce una clausola AT TIME ZONE che consente di rielaborare un'ora in un fuso orario in un altro (esempio PostgreSQL):

-- Grab a value in one time zone and convert it to another
SELECT TIMESTAMP WITH TIME ZONE '2013-01-03 12:34:56 EST' AT TIME ZONE 'MST';

-- Store it as the user provided it, in his preferred time zone
INSERT into bar (foo) VALUES ('2013-01-03 12:34:56 EST');

-- Retrieve it in its original form
SELECT foo FROM bar WHERE ... ;

-- Retrieve it in the time zone some other user prefers
SELECT foo AT TIMEZONE 'PST' FROM bar WHERE ... ;

Diversi database, Oracle e PostgreSQL tra loro, implementano questo.

I am also curious to hear some explanations why the, IMO overcomplicated time zoned datetime data type has ever been used across databases and not a uniform single time zone with conversions just for display.

Non c'è niente di complicato in questo; i tipi suddivisi in zone memorizzano solo più informazioni. A volte è importante conoscere il fuso orario in cui si è verificato un evento e la conversione in un singolo fuso orario cancella irrevocabilmente tali informazioni. Se stai facendo una promozione di marketing e vuoi sapere quali clienti hanno effettuato gli ordini durante l'ora di pranzo, un ordine che sembra essere stato piazzato a mezzogiorno del GMT non è molto utile quando è stato effettivamente messo a colazione a New York. Per ottenere tutto ciò, dovrai reinventare le ruote di cui sopra, che il tuo database potrebbe aver già fatto per te.

Questo dipende molto dallo scopo delle informazioni datetime.

Per un'app di calendario, la possibilità di tenere traccia dei fusi orari è essenziale. Per un demone di registrazione, avere tutti i record nella stessa TZ è abbastanza conveniente. Che tipo è la tua app?

OTOH Non vedo quale sarà il tuo guadagno dall'usare un int lungo per memorizzare il timestamp. Questo mi sembra un'ottimizzazione prematura; puoi anche archiviare i dati come GMT e avere gli orologi dei tuoi server sempre impostati su GMT (come molti di noi fanno). Se questo è il punto della tua domanda, allora sì, avere tutto internamente memorizzato nella stessa TZ può essere una buona idea.

Il GMT sarà sempre lo stesso senza modifiche per gli scenari di Ora legale? Potrei immaginare se improvvisamente una serie di dati di data è stata spostata a causa di DST che potrebbe essere un problema e quindi potrebbe essere necessario contemplare quali regole di business avresti per questo.

"Epic Fail" di Jon Skeet ha una sezione su Fusi orari che trovo interessante e abbastanza divertente allo stesso tempo.