2015-09-16 14 views
14

Perché non è Time.current uguale al suo equivalente analizzato?Perché questi due tempi sono diversi?

current = Time.current 
# Wed, 16 Sep 2015 17:10:56 CEST +02:00 
parsed = Time.zone.parse('16 Sep 2015 17:10:56') 
# Wed, 16 Sep 2015 17:10:56 CEST +02:00 
current == parsed 
# false <= What ?! 
current.to_i == parsed.to_i 
# true 
Ticket.create(datetime: current) 
# ... 
Ticket.find_by_datetime(parsed) 
# nil <= Why ?! 

realtà sto avendo problemi con questo in un'applicazione Ruby on Rails, dove cerco di trovare un record in base a un attributo datetime che è stato analizzato, come indicato sulle ultime righe.

Davvero non capisco. I fusi orari sono gli stessi, i tempi sono uguali a pochi secondi. Cosa sta succedendo qui?

Inoltre, come devo procedere per trovare un record basato su un tempo di riferimento analizzato?

+5

L'orologio del computer ha probabilmente una precisione inferiore al secondo ;-) (suggerimento: 'to_f') – Stefan

+0

Grazie! Ok, quindi il tempo di elaborazione analizzato non ha precisione al secondo. Ma allora cosa dovrei fare per recuperare il record nel database? –

+1

O troncare l'attributo a interi secondi prima di salvarlo nel database o passare un intervallo che copre l'intero secondo: 'Ticket.where (datetime: analizzato ... analizzato + 1)' – Stefan

risposta

5

Grazie a tutti per l'aiuto. Spero non ti dispiaccia, ma dato che i pezzi della risposta finale sono sparsi su più risposte, risponderò alla mia domanda basandomi su ciò che hai detto tutti.

Così come per il motivo per cui le date sono diverse, è a causa dei millisecondi mancanti nel tempo di elaborazione analizzato. Come @dimakura menzionato.

current.to_f #=> 1442417032.6567826 
parsed.to_f #=> 1442417032.0 

Quindi la risposta su come è possibile recuperare il record Biglietto basato sul tempo di elaborazione analizzato.

Per prima cosa è importante sapere che questo sarà rilevante solo per PostgreSQL (il mio caso) o altri database che contengono effettivamente millisecondi. Grazie a @sjagr per aver menzionato questo.

quindi dobbiamo interrogare per una gamma da analizzato per analizzato + 1 secondo, come ha spiegato @Stefan:

Ticket.where(datetime: parsed...parsed+1).first 

E se abbiamo il controllo sulla creazione del biglietto, potremmo anche togliere la precisione millisecondo prima salvare il database. Grazie a @sjagr per aver fornito un modo semplice per farlo.

current = Time.current 
Ticket.create(datetime: current.change(usec: 0)) 

Grazie a tutti!

21

Non dovrebbero essere gli stessi:

current.to_f #=> 1442417032.6567826 
parsed.to_f #=> 1442417032.0 

Durante l'analisi, si dimentica millisecondi.

+1

Potresti quindi espandere il modo in cui possiamo recuperare un record nel DB basato su una stringa analizzata che non ha precisione millisecondo? –

+1

@JeremyF. Puoi stampare 'ticket.datetime.to_f'? – dimakura

+0

1442416256.115874 –

3

È perché non sono uguali, differiscono per parti del secondo. Quello che vedi nella console è il risultato del metodo inspect chiamato in quelle date, che, per impostazione predefinita, elimina le parti secondarie secondarie.

Problemi correlati