Timestamp En Mysql

[AgeR]

 Hola, amos a ver, resulta que estoy haciendo la paginilla para las compos de stratos y me he encontrado con un problemilla.
Quería guardar las fechas de inicio y final de las compos como un campo timestamp de mysql, ya que luego sería muy fácil obtener el tiempo que resta para empezar o acabar una compo.
El problema es que cuando quiero meter una variable que contiene el timestamp, parece que no me la pilla.

Un trozo del código:

Código [Seleccionar] Expand


$inicio = mktime($inicio_h, $inicio_m, 0, $inicio_m, $inicio_d, $inicio_a);
$final = mktime($final_h, $final_m, 0, $final_m, $final_d, $final_a);
$creacion = mysql_db_query("sc", "insert compos(inicio, final, tema, bases, organizador)
values('$inicio', '$final', '$tema', '$bases', '$organiza')");


Los campos inicio y final de la tabla son de tipo timestamp. En teoría, un campo timestamp permite guardar cualquier fecha en este formato, o al menos eso creo, claro.
La función mktime convierte las horas, minutos, segundos, mes, día y año que le pasas a un timestamp.

Todos los campos se insertan bien, salvo los de inicio y final, que toman los valores por defecto y no hacen caso a lo que le paso en el insert.

No sé si en vez de un campo timestamp serviría un campo bigint simplemente.
Seguro que tengo un fallo tonto por ahí. Si alguien más versado en estos temas me puede dar una idea...  :rolleyes:

Bueno, esta semana espero tener plenamente funcional la web de las compos, para que podáis empezar a sugerir mejoras y adecentar la web.

[CoLSoN2]

 No se a que se debe este problema pero yo también lo tuve, y acabé usando campos BIGINT para guardar el timestamp.

EDIT: Por cierto, esta sintaxis para integrar variables en un string está permitido en PHP?

$creacion = mysql_db_query("sc", "insert compos(inicio, final, tema, bases, organizador)
values('$inicio', '$final', '$tema', '$bases', '$organiza')");

Yo es que siempre hago algo como "insert into tabla values (".$num.", '".$string."')" y cuando tienes muchos campos tantas comillas y puntos resultan molestos.

[MA]Mestre]

 - Las inserciones de fechas normalemete se suelen hacer entre comillas simples como las cadenas.
- Antes que usar un bigint ( lol ) usa el Date ( Fecha ) o DateTime ( FechaHora ).

Un saludo ^_^

[zupervaca]

 en sql las fechas realmente son strings camuflados

[TheWind]

Hola, amos a ver, resulta que estoy haciendo la paginilla para las compos de stratos y me he encontrado con un problemilla.
Quería guardar las fechas de inicio y final de las compos como un campo timestamp de mysql, ya que luego sería muy fácil obtener el tiempo que resta para empezar o acabar una compo.
El problema es que cuando quiero meter una variable que contiene el timestamp, parece que no me la pilla.

Un trozo del código:

Código [Seleccionar] Expand


$inicio = mktime($inicio_h, $inicio_m, 0, $inicio_m, $inicio_d, $inicio_a);
$final = mktime($final_h, $final_m, 0, $final_m, $final_d, $final_a);
$creacion = mysql_db_query("sc", "insert compos(inicio, final, tema, bases, organizador)
values('$inicio', '$final', '$tema', '$bases', '$organiza')");


Los campos inicio y final de la tabla son de tipo timestamp. En teoría, un campo timestamp permite guardar cualquier fecha en este formato, o al menos eso creo, claro.
La función mktime convierte las horas, minutos, segundos, mes, día y año que le pasas a un timestamp.

Todos los campos se insertan bien, salvo los de inicio y final, que toman los valores por defecto y no hacen caso a lo que le paso en el insert.

No sé si en vez de un campo timestamp serviría un campo bigint simplemente.
Seguro que tengo un fallo tonto por ahí. Si alguien más versado en estos temas me puede dar una idea...  :rolleyes:

Bueno, esta semana espero tener plenamente funcional la web de las compos, para que podáis empezar a sugerir mejoras y adecentar la web.

Varias cosas:

De entrada la sintaxis correcta para que las variables sean sustituidas en una cadena por sus valores es cuando la cadena esta delimitada por comillas dobles y no simples ("$zz" en lugar de '$zz')

Quizas no es lo mas adecuado por el comportamiento de los timstamp, ya que el campo timestamp siempre se actualiza cuando se toca el registro y hay q leer y reactualizar para que no se pierda la informacion.

Luego hay un problema con el formato de los timestamp en la 3.2x y la 4.1.x ya que en esta ultima se ha pasado a ser un timestamp unix convencional en lugar de las 4.0.x y anteriores que tenian un formato propio.

Para realizar operaciones con fechas, o bien usas bigint's o usas un campo datetime normal y lo transformas a la entrada y salida... aprovechando si quieres el SQL para realizar las operaciones con las fechas.

[MA]Mestre]

 zupervaca
En un SGBD los datos de fecha son nativos, como mucho podemos decir que son bytes camufaldos :D. No se si podemos definir al MySQL como SGBD. ( No )

TheWind
He presupuesto que el codigo que nos ha puesto era para simplificar. Pues Ager no se queja de la introduccion del resto de valores ;). Como bien dices para separar texto literal de las variables se han de poner comillas dobles. Ahora, los campos cadena y fecha en un SGBD deben ser tratados con comilla simples detras y delante. (SQL'92)


"insert into tabla values (" + $entero + ",'" + $cadena + "','" + $fecha + "')"



Usar bigint es como poner en C un break para salir de un bucle... ...efectivo, pero poco elegante ;)

Un saludo

[zupervaca]

 sorry pense que se hablaba del mysql por el topic mas que nada

[MA]Mestre]

 sorrry, solo trataba de explicarte que lo que decias era mentira de una forma elegante.  :D  

[AgeR]

Por cierto, esta sintaxis para integrar variables en un string está permitido en PHP?

$creacion = mysql_db_query("sc", "insert compos(inicio, final, tema, bases, organizador)
values('$inicio', '$final', '$tema', '$bases', '$organiza')");

Yo es que siempre hago algo como "insert into tabla values (".$num.", '".$string."')" y cuando tienes muchos campos tantas comillas y puntos resultan molestos.

Yo siempre he usado esa sintaxis y me ha funcionado bien para todos los tipos de campos hasta ahora, salvo los dichos timestamps parece ser.

Aunque no sea la solución perfecta creo que usaré bigints, me parece más cómodo y rápido que andar con conversiones de fechas cada vez  :ph34r:  

[MA]Mestre]

 Pq no pruebas usar un Datetime ? :D

Alter table x
alter column xxxx datetime;

MySQL Doc


P.D: Nunca habia visto esa sintaxis que usas :D

[zupervaca]

 

Mestre"] sorrry, solo trataba de explicarte que lo que decias era mentira de una forma elegante.  :D

como que mentira? en mysql el formato de la fecha es en formato string asi: AAAA-MM-DD, en otras bases de datos no lo se, pero en mysql si

editado: pero si es que el propio link que pones es asi, vaya gente

[MA]Mestre]

 zupervaca
en sql las fechas realmente son strings camuflados

a.) Las fechas son valores enteros camuflados.

b.) Las fechas se codifican en segundos, centésimas o milésimas. ( dependiendo de la precisión del tipo de dato del SGBD )

c.) Las fechas suelen tener un base desde la cual se empiezan.
Por Ejemplo el TimeStamp en MsSQL 4.1
The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.

d.) Con sumas se incremtan dias, meses, años, etc. ( facil, facil )

e.) Con restas se calculan diferencias de fechas. ( facil, facil )

f.) Las comparaciones entre fechas agiles y rápidas ( facil, facil )

g.) Existen funciones propias del gestor para convertir fechas a cadenas.

Si un fecha fuera realemnte un string:

a.) Ocuparian más espació que si son numericas.
b.) No tendrian una base de fecha inicial y no estarian limitadas en rango de años.
c.) Sumas, restas y comparaciones serian muy lentas.
d.) No existirian funciones propias del gestor para la conversion de fechas a cadenas.


Ejercicio puntuable:

¿ Como gestiona una bios la fecha/hora/seg ?


Nota:

Nada más faltaba que un usuario tubiera que insertar una fecha en milisegundos en un gestor de bbdd  :D.

Un saludo.

[zupervaca]

 

zupervaca
en sql las fechas realmente son strings camuflados

¿entonces por que dices que antes estaba mintiendo? la verdad es que no entiendo a algunos usuarios

[MA]Mestre]

 Pq una fecha no es realemente un string camufaldo.

Una fecha es un entero camufaldo ( con algun matiz ).

P.D: Creo que me exprese con claridad, en el post anterior. Si no es así que alguien más me lo diga pq me voy a empezar a preocupar  :blink:  

[zupervaca]

 veamos me parece que tu hablas de como se guarda en la base de datos y yo hablo del lenguaje sql que son cosas diferentes

editado: un ejemplo

- oracle (base de datos) se comunica con el programador mediante sql (lenguaje), mi primer post estaba bien, sql es un lenguaje y es a lo que me referia