Newsgroup: it.comp.software.database
Titolo: campo data

Salve a tutti
ho importato un campo data da una piattaforma sqlite , la data nel db
è espressa come segue (1313322256425) e non con la classica
notazione.
come posso fare a risalire alla data e l'ora ?
grazie 1000


sicuro che il numero e' quello ? su postgres:
 
# SELECT to_timestamp(1313322256425);
to_timestamp          
--------------------------------
43587-07-12 03:53:44.999936+02
(1 row)
 
-- 
Never try to teach a pig to sing.
It wastes your time and annoys the pig.


A occhio e croce e` stato creato da un'applicazione Java (o qualcosa del 
genere). Dovrebbero essere millisecondi dal 1 gennaio 1970.
 
Dividi per 1000, prendi la parte intera e usa date()
 
Bye.
 

 Dividi per 1000, prendi la parte intera e usa date()
 
Sorry, pensavo di essere nel ng di PHP.
 
Io la terrei cosi` nel DB (lo faccio per tutte le date), e gestirei a 
livello applicazione tutte le conversioni.
 
Bye.
 

 Dividi per 1000, prendi la parte intera e usa date()
 
cosi' mi trovo ;-)
 
SELECT to_timestamp(1313322256);
to_timestamp      
------------------------
2011-08-14 13:44:16+02


 Bye.
 
Ciao,
 
Lucazeo.

 Faccio fatica ad immaginare i vantaggi, quali sarebbero?
 
I vantaggi sono che:
 
- non dipendi dalla configurazione del server per il formato tornato (se 
il server ha locale US ti trovi m/d/Y, se ha locale IT hai d/m/Y, per 
esempio in MySQL). OK, i framework di solito astraggono questo problema, 
ma non e` garantito.
 
- idem come sopra per la timezone
 
- appunto usi il motore aritmetico invece di quello per le date, che puo` 
essere piu` efficiente e, in alcuni DB, meglio indicizzabile
 
- hai lo stesso formato in tutte le piattaforme e in tutti i linguaggi, 
ma anche in tutti i DB. Non devi preoccuparti di fare o usare un ORM per 
astrarre la conversione delle date tra DB diversi.
 
 
Personalmente ho provato per molto tempo a usare il formato "data" dei DB, 
ma mi sono sempre trovato meglio ad usare il classico timestamp Unix (o 
"Java" se servono i millisecondi).
 
Bye.
 

Il Wed, 04 Jan 2012 12:27:30 -0800, rwen ha scritto:
 

Auguri!
 
Non è di certo un timestamp UNIX:
 
manlio=> SELECT to_timestamp(1313322256425);
          to_timestamp          
--------------------------------
 43587-07-12 03:53:44.999936+02
(1 riga)
 
 
sqlite> select datetime(1313322256425, 'unixepoch');
-1413-03-01 13:07:12
 
 
Dovresti scoprire quale applicazione ha inserito quel dato, ed il formato 
che ha usato.
 
 
Ciao  Manlio

 
 
secondo me non sono dei gran vantaggi.
 
quei vantaggi che evidenzi sono significativi solo quando una applicazione 
non lavora sui campi di tipo data/ora trattandoli come oggetti di tipo 
'data/ora' ma come stringhe, perche' in un database un campo di tipo 
'data/ora' contiene l'informazione e basta: il formato entra in gioco solo 
quando converti l'informazione in stringa.
 
il locale del server puo' influire sul formato utilizzato per visualizzare 
l'informazione, non sull'informazione in se', solo se la visualizzi tramite 
una interfaccia che sceglie il formato di visualizzazione in base al locale 
del server.
 
a quel punto pero' e' l'applicazione che non gestisce in maniera robusta le 
date.
 
 
-- 
Paolo opg
 
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--