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 OOP "legacy" non è il modo per farlo nel mondo di oggi, ad esempio, non (leggi:non dovrebbe essere) usando un INT datatype nel nostro database per memorizzare le date in formato Unix Timestamp, dovremmo invece utilizzare il tipo nativo del database che di solito è un DATE o DATETIME tipo che coopera con DateTime di PHP oggetto (e altri linguaggi') quasi in modo nativo quando si tratta di conversioni standard.
Per approfondire un po' cosa intendo per conversioni standard:quando usi MySQL e riporti un valore in PHP ottieni una stringa di data formattata ISO, di cui il DateTime la classe analizza nel suo costruttore dandoti un oggetto immediatamente utilizzabile. Al contrario, per seguire il percorso del timestamp di Unix dovresti usare strtotime , allora date per inserirlo in qualsiasi formato desideri nativamente.
Ho menzionato prima l'interoperabilità tra i nostri sistemi PHP e i sistemi .NET. Sebbene non ci siano problemi specifici causati dall'utilizzo di un timestamp, semplicemente non è la soluzione pratica, poiché, ancora una volta, utilizziamo un database che restituisce un valore DateTime che può essere inviato direttamente nel tubo. Se dovessimo convertirlo in un timestamp unix da utilizzare internamente in PHP, dovremmo anche riconvertirlo se dovessimo inviare una risposta o inviare una risposta all'applicazione .NET (o dovrei semplicemente dire API in questo caso) che è un timestamp e convertirlo alla fine. Usando DateTime su tutta la linea, allevia la necessità che qualsiasi conversione avvenga e l'intero processo di sviluppo è più semplice.
Infine, per aggiungere a tutto questo, come hai menzionato anche nel tuo post, puoi usare oggetti brillanti come DateInterval , fuso orario più semplice, manipolazione più semplice e formattazione più semplice ecc. quando usi DateTime ed è correlato ai partner nel crimine orientati agli oggetti. È solo un processo di sviluppo più semplice ai miei occhi.
Non credo, come ho detto inizialmente, che ci sia una risposta "corretta" a questa, solo più una preferenza personale basata sul tuo stile di codifica, e i commenti sopra riflettono il mio.
- Non credo in alcun modo. Soprattutto con gli script PHP che generalmente sono processi così brevi.
Sì :)
Vedi i commenti sopra sul database, non è "nativo" usare un Timestamp Unix per questo scopo IMO. Puoi semplicemente chiamare ->getTimezone e salvalo nel database, quindi usa ->setTimezone quando lo estrai di nuovo.
