¿Cuándo elegimos DateTime sobre Timestamp?

Como paso la mayor parte de mi time con php y mysql o pgsql, usaré DateTime como una palabra genérica para la API de date. En php no hay "Fecha", "Hora", "DateTime" y "DateTimeOffset"

A medida que desarrollo aplicaciones web cada vez más elaboradas, uso DateTime la mayor parte del time, pero a veces me pregunto si realmente es lo que quiero. por ejemplo, sucede que solo quiero mostrar la date de hoy (por ejemplo, cuando quiero almacenar un foro o publicación de blog), no hay ningún cálculo, ni filter para proporcionar, ni iteración para que ocurra … Entonces, ¿por qué uso? \DateTime sobre la function date() ?

Vi este tema que proporciona una descripción simple de los pros de cada tecnología.

Pero realmente no responde a la pregunta. ¿Es realmente una pérdida arrojar 2 bytes más en un object DateTime en PHP y otros 2 bytes en mi database, ya que me permite usar la API DATE_INTERVAL (en php es DateInterval ) y la IntlDateFormatter.

Además, este post dice que unix_timestamp está reservado desde 1970. Pero no es lógico y algunas testings lo demuestran:

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

¡ecos '31 / 12/1969 '! Y es lógico. Un int sin signo de 32 bits va de 0 a 4 294 967 295 y solo hay casi 2 mil millones de segundos en 68 años, ¡así que el int está firmado y debe existir "timestamp negativo"!

Otro piensa que es realmente importante para mí, y eso me hace elegir DateTime cada vez que quiero lidiar con dates, no con integers. ¡DateTime es una date, la timestamp no lo es! La única sensación que encontré en la timestamp fue la hora en que quería marcar el time de un nombre de file porque en esa timestamp cas está la timestamp …

Sin embargo, todavía hay un problema: event handling la zona horaria. Como MySQL y otros no manejan la zona horaria al almacenar dates como DateTime, por ahora, uso la integración de TimeZone como la parte de escape de "filtrar en escape out"

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

¿Es el path correcto? ¿No sería mejor almacenar una timestamp simple y luego get la buena hora local?


Entonces, aquí hay un resumen de la pregunta:

  • Son los 2 bytes más de DateTime una pérdida en el uso realmente simple de la API (solo se muestra)
  • ¿Es el momento de renunciar a unix_timestamp?
  • ¿No sería mejor almacenar una timestamp simple y luego get la buena hora local?

Como dije en un comentario, creo que esto se debe principalmente a las preferences personales. Desde mi punto de vista, el uso de una timestamp Unix y interfaces henetworkingadas no OOP no es la manera de hacerlo en el futuro, por ejemplo, no usamos (lee: no debería ser) un tipo de datos INT en nuestra database para almacenar dates en formatting Unix Timestamp, deberíamos usar el tipo nativo de la database, que generalmente es un tipo DATETIME o DATETIME que coopera con el object DateTime de PHP (y otros lenguajes) casi nativamente cuando se trata de conversiones estándar.

Para explicar un poco sobre lo que quiero decir con las conversiones estándar: Cuando usas MySQL y recuperas un valor para PHP, obtienes una cadena de date con formatting ISO, cuya class DateTime analiza en su constructor, proporcionándote un object inmediatamente utilizable. Por el contrario, para ir a la ruta de la timestamp de Unix, debe usar strtotime , luego date para get el formatting que desee de forma nativa.

Mencioné antes sobre interoperabilidad entre nuestros sistemas PHP y .NET. Si bien no hay problemas específicos causados ​​por el uso de una timestamp, simplemente no es la solución práctica, ya que de nuevo, utilizamos una database que devuelve un valor DateTime que se puede enviar directamente a través de la tubería. Si tuviéramos que convertir esto a una timestamp Unix para usarlo internamente en PHP, también tendríamos que convertirlo de nuevo si tuviéramos que enviar una respuesta, o enviar una respuesta a la Aplicación .NET (o debería simplemente decir API en este caso) que es una timestamp y la convierte al final. Al utilizar DateTime todos los ámbitos, alivia la necesidad de que las conversiones sucedan en cualquier caso y todo el process de desarrollo es más fácil.

Finalmente, para agregar a todo esto, como también mencionó en su publicación, puede usar elementos shinys como DateInterval , timezoning más fácil, manipulación más fácil y formatting más fácil, etc., cuando usa DateTime y está relacionado con socios orientados a objects en el crimen. Es solo un process de desarrollo más fácil para mí.

No creo, ya que inicialmente dije que hay una respuesta "correcta" a esto, solo una preference personal basada en su propio coding style, y los comentarios anteriores reflejan los míos.

Son los 2 bytes más de DateTime una pérdida en el uso realmente simple de la API (solo se muestra)

  • No lo creo de ninguna manera. Especialmente con los scripts PHP generalmente siendo processs tan cortos en ejecución de todos modos.

¿Es el momento de renunciar a unix_timestamp?

Sí 🙂

¿No sería mejor almacenar una timestamp simple y luego get la buena hora local?

Consulte los comentarios anteriores en la database, no es "nativo" utilizar una timestamp de Unix para este propósito IMO. Puede llamar a ->getTimezone y almacenar esto en la database, luego use ->setTimezone cuando lo saque de nuevo.

No es una respuesta exacta a su pregunta, pero elegiría Timestamp sobre DateTime , porque CREO que trabajar en un valor Integer es mucho más rentable (medir el time de procesamiento de la CPU), en lugar de procesar los valores de DateTime .

Me siento muy cómodo cuando tengo Numbers en una Binary Machine , en lugar de Strings o Objects .

Humano vs. Máquina

En términos de Comprensibilidad , diría que cuando estoy escribiendo un progtwig para una computadora, consideraría que estoy haciendo eso para que una Machine trabaje en eso, sin embargo, si una abstracción sobre esa capa pudiera ayudar a los humanos a entender mejor, ¿por qué no lo usamos cuando Performance no es un problema?

No recuerdo quién dijo o dónde lo escuché, pero alguien dijo algo así como: "La People hate Computers, but they should hate Programmers , y estoy totalmente de acuerdo con eso. Entonces, como ser humano, sigo respetando esa máquina e intentaré hacer progtwigs que sean más comprensibles para las computadoras. 🙂

Actualizar:

Para imaginarlo mejor, imagina que tenemos un progtwig para lidiar con 'Fechas', procesando 10,000 veces por minuto, ¿verdad?

 // it LOOKS Better $date = new DateTime(); $date->setDate(1986, 3, 24); // March 24, 1986 echo $date->format('Ym-d'); // it WORKS Better echo date("Ymd", mktime(0, 0, 0, 3, 24, 1986)); // March 24, 1986 

Digamos que tengo que mirar este código una hora por semana, y supongamos que hay 10.000 personas con las que deberían lidiar las 24 horas del día, los 365 días del año, y por supuesto que no voy a manejar eso, es una tarea para un máquina.

Por cierto, volvería a decir que si el Performance no es un problema, ¿por qué no lo hacemos más comprensible para los progtwigdores? Si necesitamos sacar el máximo provecho de eso, entonces dejemos que los progtwigdores observen el código que Works mejor, ¡no se Looks ! 🙂