Quando scegliamo DateTime su Timestamp

Question

Mentre trascorro la maggior parte del mio tempo con php e mysql o pgsql, userò DateTime come parola generica per l'API della data. In php non ci sono "Date", "Time", "DateTime" e "DateTimeOffset"

Mentre sviluppo un'applicazione web sempre più elaborata, uso DateTime la maggior parte del tempo, ma a volte mi chiedo se sia davvero quello che voglio. per esempio succede che voglio solo visualizzare la data odierna (per esempio quando voglio memorizzare un forum o post di un blog), non c'è calcolo, nessun filtro da fornire, nessuna iterazione da accadere ... Allora perché io utilizzare \DateTime sulla funzione date()?

Ho visto this topic che fornisce una semplice descrizione dei vantaggi di ciascuna tecnologia.

Ma in realtà non risponde alla domanda. È davvero una perdita buttare ancora 2 byte in un oggetto DateTime in PHP e altri 2 byte nel mio database in quanto mi permette di usare l'API DATE_INTERVAL (in php è DateInterval) e IntlDateFormatter.

Inoltre, questo post dice che UNIX_TIMESTAMP è riservato dal 1970. Ma non è logico e alcuni test lo dimostrano:

echo date('d/m/Y',time(-1)); 

echi '31/12/1969' ! Ed è logico. Un int con 32 bit senza segno va da 0 a 4 294 967 295 e ci sono solo quasi 2 miliardi di secondi in 68 anni, quindi l'int è firmato e "timestamp negativo" deve esistere!

Un'altra cosa che per me è davvero importante, e che mi fa scegliere DateTime ogni volta è che voglio trattare le date, non con i numeri interi. DateTime è una data, timestamp no! L'unica sensazione che ho trovato nel timestamp è stata la volta in cui volevo segnare un nome di file perché in quel cas timestamp è timestamp ...

Tuttavia, c'è ancora un problema: gestione del fuso orario. Come MySQL e altri non gestisce fuso orario durante la memorizzazione di date come DateTime, per il momento, io uso l'integrazione TimeZone come la parte uscita di "filtro in uscita fuori"

$toStoreDate = new \DateTime($_POST['date'],new DateTimeZone('UTC')); 
$dao->exec('INSERT INTO mytable(mydate) VALUES (\''.$toStoreDate->format('Y-m-d h:i:s').'\')'); 
$toDisplayDate =new \DateTime($dao->query('SELECT mydate FROM mytable') 
    ->fetch(DAO::FETCH_ASSOC)['mydate']); 
$toDisplayDate->setTimeZone(new DateTimeZone('myLocal')); 

E 'la strada giusta? Non sarebbe meglio memorizzare un semplice timestamp e ottenere la buona ora locale?

---

Quindi, ecco un summarize della questione:

• Is i 2 più byte di DateTime una perdita di molto semplice l'utilizzo delle API (solo visualizzazione)
• E 'il momento rinunciare a unix_timestamp?
• Non sarebbe meglio memorizzare un semplice timestamp e ottenere la buona ora locale?

Answer 1

Come detto in un commento, credo che questo sia principalmente dovuto alle preferenze personali. Ai miei occhi, l'uso di un timestamp Unix e di interfacce "non legacy" non OOP non è il modo di farlo andare avanti nel mondo di oggi, ad esempio, non lo facciamo (leggi: non dovrebbe essere) utilizzando un tipo di dati INT nel nostro database per memorizzare le date nel formato Unix Timestamp, dovremmo invece utilizzare il tipo nativo del database che di solito è un tipo DATE o DATETIME che collabora con l'oggetto PHP DateTime (e altre lingue) quasi in modo nativo quando si tratta di conversioni standard.

di elaborare un po 'su quello che intendo per conversioni standard: quando si utilizza MySQL e tirare indietro di un valore a PHP si ottiene una stringa data ISO-formattato, di cui la classe DateTime analizza in esso del costruttore dandovi immediatamente utilizzabile oggetto. Al contrario, per utilizzare la route timestamp Unix è necessario utilizzare strtotime, quindidate per ottenerlo in qualsiasi formato si desideri in modo nativo.

Ho parlato prima dell'interop tra i nostri sistemi PHP e i sistemi .NET. Anche se non ci sono problemi specifici causati dall'uso di un timestamp, semplicemente non è la soluzione pratica, come di nuovo, usiamo un database che restituisce un valore DateTime che può essere inviato direttamente lungo la pipe. Se dovessimo convertire questo in un timestamp unix da usare internamente in PHP, dovremmo anche convertirlo nuovamente se dovessimo inviare una risposta, o inviare una risposta all'applicazione .NET (o dovrei solo dire API in questo caso) che è un timestamp e convertirlo alla fine. Usando lo standard DateTime, allevia la necessità che qualsiasi conversione avvenga in qualsiasi momento e l'intero processo di sviluppo è più semplice.

Infine da aggiungere a tutto questo, come lei ha ricordato anche nel tuo post, si arriva a usare oggetti luccicanti, come DateInterval, più facile timezoning, facile manipolazione e più facile la formattazione ecc quando si utilizza DateTime ed è legato partner orientati agli oggetti nel crimine. È solo un processo di sviluppo più semplice ai miei occhi.

Non credo come inizialmente ho detto che c'è una risposta "corretta" a questo, solo più di una preferenza personale basata sul proprio stile di codifica, e i commenti sopra riflettono il mio.

Is i 2 più byte di DateTime una perdita di molto semplice l'utilizzo delle API (solo visualizzazione)

• Non credo quindi in alcun modo. Soprattutto con gli script PHP in genere sono comunque processi di esecuzione così brevi.

È il momento di rinunciare a unix_timestamp?

Sì :)

Non sarebbe meglio per memorizzare un semplice timestamp e quindi ottenere il tempo locale?

Vedere i commenti precedenti sul database, non è "nativo" utilizzare un Unix Timestamp per questo scopo IMO. È sufficiente chiamare lo ->getTimezone e archiviarlo nel database, quindi utilizzare ->setTimezone quando lo si ritira di nuovo.

Answer 2

Non una risposta esatta alla tua domanda, ma vorrei scegliere Timestamp sopra DateTime, perché io CREDO lavorando su un valore di Integer è molto più redditizio (misurando il tempo di elaborazione della CPU), piuttosto elaborazione DateTime valori.

mi sento molto comodo quando ho Numbers su un Binary Machine, piuttosto avendo Strings o Objects.

Umano vs macchina

In termini di comprensibilità , direi quando sto scrivendo un programma per un computer, vorrei prendere in considerazione che sto facendo che per un Machine a lavorare su questo, tuttavia, se un'astrazione su quel livello potrebbe aiutare gli umani a capirlo meglio, perché non lo usiamo quando lo Performance non è un problema?

Non riesco a ricordare chi ha detto o dove l'ho sentito, ma qualcuno ha detto qualcosa come People hate Computers, but they should hate Programmers e sono totalmente d'accordo. Quindi, come umano, continuo a mantenere il rispetto di quella macchina e cercherò di creare programmi più comprensibili per i computer. :)

Aggiornamento:

Per picture meglio, immaginare abbiamo un programma a che fare con 'date', elaborazione 10.000 volte al minuto, giusto?

// it LOOKS Better 
$date = new DateTime(); 
$date->setDate(1986, 3, 24); // March 24, 1986 
echo $date->format('Y-m-d'); 

// it WORKS Better 
echo date("Y-m-d", mktime(0, 0, 0, 3, 24, 1986)); // March 24, 1986 

Let dire che ho di guardare a questo codice per un'ora a settimana, e lasciare che dicono che ci sono 10.000 persone che dovrebbero affrontare questo 24/7/365 e naturalmente io non sono maniglia andando questo è un compito per una macchina.

A proposito, vorrei ribadire che se lo Performance non è un problema, perché non lo rendiamo più comprensibile per i programmatori? Se abbiamo bisogno di ottenere il massimo da ciò, allora lascia che i programmatori guardino meglio il codice Works, non Looks! :)