Como dije en un comentario, creo que esto se debe principalmente a preferencias personales. En mi opinión, el uso de una marca de tiempo de Unix y las interfaces "heredadas" que no son OOP no es la forma de hacerlo en el mundo actual, por ejemplo, no usamos (léase:no deberíamos) usar un INT tipo de datos en nuestra base de datos para almacenar fechas en formato Unix Timestamp, en su lugar deberíamos usar el tipo nativo de la base de datos, que generalmente es DATE o DATETIME tipo que coopera con DateTime de PHP object (y otros lenguajes) casi de forma nativa cuando se trata de conversiones estándar.
Para profundizar un poco en lo que quiero decir con conversiones estándar:cuando usa MySQL y recupera un valor en PHP, obtiene una cadena de fecha con formato ISO, de la cual DateTime la clase analiza en su constructor y le brinda un objeto inmediatamente utilizable. Por el contrario, para ir a la ruta de marca de tiempo de Unix, tendría que usar strtotime , entonces date para obtener el formato que desee de forma nativa.
Mencioné antes acerca de la interoperabilidad entre nuestros sistemas PHP y los sistemas .NET. Si bien no hay problemas específicos causados por el uso de una marca de tiempo, simplemente no es la solución práctica, ya que nuevamente, usamos una base de datos que devuelve un valor DateTime que se puede enviar directamente por la tubería. Si tuviéramos que convertir esto a una marca de tiempo de Unix para usar internamente en PHP, también tendríamos que volver a convertirlo si tuviéramos que enviar una respuesta, o enviar una respuesta a la aplicación .NET (o debería decir API en este caso) que es una marca de tiempo, y convertirlo al final. Usando DateTime en general, alivia la necesidad de que se produzcan conversiones y todo el proceso de desarrollo es más fácil.
Finalmente, para agregar a todo esto, como también mencionaste en tu publicación, puedes usar elementos brillantes como DateInterval , división horaria más fácil, manipulación más fácil y formateo más fácil, etc. cuando usa DateTime y sus socios orientados a objetos relacionados en el crimen. En mi opinión, es un proceso de desarrollo más fácil.
No creo, como dije inicialmente, que haya una respuesta "correcta" a esto, solo una preferencia personal basada en su propio estilo de codificación, y los comentarios anteriores reflejan el mío.
- No lo creo de ninguna manera. Especialmente dado que los scripts PHP generalmente son procesos de ejecución tan cortos de todos modos.
Sí :)
Consulte los comentarios anteriores sobre la base de datos, no es "nativo" usar una marca de tiempo de Unix para este propósito, en mi opinión. Simplemente puede llamar a ->getTimezone y almacene esto en la base de datos, luego use ->setTimezone cuando lo vuelvas a sacar.
