2012-09-27 32 views
5

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?
+0

Probablemente irrelevante, pero 'date()' solo funcionará hasta 2038 años. En ese año, 'date()' probablemente estará en desuso ;-) –

+0

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

+0

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

Respuesta

3

Como dije en un comentario, creo que esto se debe principalmente a las preferencias personales. En mi opinión, el uso de una marca de tiempo Unix y de interfaces heredadas no OOP no es la manera de hacerlo en el futuro, por ejemplo, no lo hacemos (léase: no debería ser así) usando un tipo de datos INT en nuestra base de datos para almacenar fechas en formato Unix Timestamp, deberíamos usar el tipo nativo de la base de datos que generalmente es un tipo DATE o DATETIME que coopera con el objeto 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 conversiones estándar: Cuando utiliza MySQL y recupera un valor para PHP, obtiene una cadena de fecha con formato ISO, cuya clase DateTime analiza en su constructor proporcionándole un uso inmediato objeto. Por el contrario, para ir a la ruta de marca de tiempo Unix, deberá usar strtotime, y luegodate para obtener el formato que desee de forma nativa.

He mencionado antes acerca de la interoperabilidad entre nuestros sistemas PHP y .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 de nuevo, utilizamos una base de datos que devuelve un valor de DateTime que puede enviarse directamente. Si tuviéramos que convertir esto a una marca de tiempo 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 marca de tiempo y la convierte al final. Al usar DateTime en todos los ámbitos, alivia la necesidad de que ocurra cualquier conversión y todo el proceso de desarrollo es más fácil.

último que añadir a todo esto, como también se mencionó en su puesto, se llega a utilizar objetos brillantes, como DateInterval, más fácil timezoning, fácil manipulación y fácil formato etc cuando se utiliza DateTime y que está relacionado socios orientados a objetos en crimen. Es solo un proceso de desarrollo más fácil para mí.

No creo como inicialmente dije que hay una respuesta "correcta" a esto, solo una preferencia personal basada en su propio estilo de codificación, y los comentarios anteriores reflejan los míos.

es el 2 bytes más de DateTime una pérdida en uso muy simple de la API (sólo visualización)

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

¿Es el momento de abandonar unix_timestamp?

Sí :)

¿No sería mejor almacenar una marca de tiempo simple y luego obtener el buen tiempo local?

Consulte los comentarios anteriores en la base de datos, no es "nativo" utilizar una marca de tiempo Unix para este propósito IMO. Simplemente puede llamar al ->getTimezone y almacenar esto en la base de datos, luego use ->setTimezone cuando lo vuelve a sacar.

+0

Me gusta mucho esta respuesta. Usted sigue mi punto de vista en cierto sentido. Aparte de, tal vez, que olvidó el hecho de que DateTime :: createFromFormat le permite crear una fecha de unixtimestamp (y también puede obtener una unixtimestamp de su objeto DateTime por formato ('u') o métodos getTimestamp) – artragis

+0

Por supuesto . Creo que este problema también se debe al hecho de que PHP ofrece un millón de maneras diferentes de realizar una única tarea simple. Mi punto principal era utilizar 'DateTime' y su constructor nativo para construir una instancia directamente desde la fecha formateada ISO que de todos modos obtendrías. De esta forma estás leyendo/escribiendo directamente desde la instancia. Para leerlo desde MySQL como una marca de tiempo, usaría 'createFromFormat', y luego también tendría que formatearlo cuando lo esté escribiendo * en * la base de datos. Sobrecarga innecesaria, IMO. –

1

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

me siento mucho cómodo cuando tengo Numbers en un Binary Machine, en lugar tener Strings o Objects.

humano contra la máquina

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

No puedo recordar quién dijo o dónde escuché eso, pero alguien dijo algo como 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 programas que sean más comprensibles para las computadoras. :)

Actualización:

imaginarlo mejor, imaginemos que tenemos un programa para hacer frente a 'fechas', procesamiento de 10.000 veces por minuto, ¿verdad?

// 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 

Digamos que tengo que mirar el código de una hora por semana, y dejar que dicen que hay 10.000 personas que deben ocuparse de que 24/7/365 y por supuesto no voy a mango eso, es una tarea para una máquina.

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

+1

gracias por su respuesta. Yo diría que prefiero la vista "escribir programas comprensibles para humanos" porque todos pueden escribir algo "comprensible por una computadora". Además, las consultas sql dan como resultado una cadena, lo que significa conversión cada vez que maneja la fecha en un script php. Y PHP no se conoce como un lenguaje muy rentable (lo mismo para Java o .NET) – artragis

+0

@artragis hey, he actualizado la respuesta, con respecto a su comentario. :) – Mahdi

+1

votó su respuesta pero no la aceptó. Mi problema es que * realmente * es un desastre tratar fechas, períodos, etc. con un número entero. Calcular intervalos de fechas con solo enteros es reinventar la rueda pero con menos legibilidad – artragis

Cuestiones relacionadas