Como paso la mayor parte de mi tiempo con php y mysql o pgsql, usaré DateTime como una palabra genérica para la API de fecha. En php no hay "Fecha", "Hora", "DateTime" y "DateTimeOffset"Cuándo elegimos DateTime sobre Timestamp
A medida que desarrollo la aplicación web cada vez más elaborada, uso DateTime la mayor parte del tiempo, pero a veces me pregunto si realmente es lo que quiero. por ejemplo, si solo quiero mostrar la fecha de hoy (por ejemplo, cuando quiero almacenar un foro o publicación de blog), no hay ningún cálculo, ni filtro para proporcionar, ni iteración que suceda ... Entonces, ¿por qué? use \DateTime
sobre la función date()
?
Vi this topic 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 objeto DateTime en PHP y otros 2 bytes en mi base de datos ya que me permite usar la API DATE_INTERVAL
(en php es DateInterval
) y la IntlDateFormatter.
Por otra parte, este post dice que UNIX_TIMESTAMP está reservado desde 1970. Pero no es lógico y algunas pruebas 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, por lo que el int se firma y debe existir "timestamp negativo".
Otra opinión que es realmente importante para mí, y que me hace elegir DateTime cada vez es que quiero tratar con fechas, no con números enteros. ¡DateTime es una fecha, la marca de tiempo no lo es! La única sensación que encontré en la marca de tiempo fue la hora en que quería marcar un nombre de tiempo porque en esa cas timestamp es timestamp ...
Sin embargo, todavía hay un problema: el manejo de la zona horaria. como MySQL y otros no maneja zona horaria cuando se almacena fechas como DateTime, por ahora, utilizo la integración de zona horaria como la parte de escape de "filtro en escapar"
$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'));
¿Es el camino correcto? ¿No sería mejor almacenar una marca de tiempo simple y luego obtener la buena hora local?
Por lo tanto, aquí hay una resumir de la siguiente pregunta:
- es el 2 bytes más de DateTime una pérdida en uso muy simple de la API (sólo visualización)
- ¿Es el momento renunciar a unix_timestamp?
- ¿No sería mejor almacenar una marca de tiempo simple y luego obtener la buena hora local?
Probablemente irrelevante, pero 'date()' solo funcionará hasta 2038 años. En ese año, 'date()' probablemente estará en desuso ;-) –
incluso si en 2038 el sistema de 64 bits fuera el estándar? Y si no, ¿cuál es el problema con la migración de la especificación de marca de tiempo de Unix de int a long int? – artragis
De hecho. Javascript incluso usa milisegundos a partir del 1/1/1970 para medir el tiempo. Supongo que la marca de tiempo de UNIX está aquí para quedarse ^^ – Johan