Veo una incoherencia en Oracle.
La incoherencia entre el modo de INSERCIÓN de marca de hora data_type valor en la FECHA de data_type columna trabaja en comparación con la forma de REPARTO(marca como FECHA de) obras.

INSERTAR parece simplemente cortar los milisegundos de la marca de tiempo del valor, mientras que en FUNDICIÓN de rondas de ellos hasta el más cercano segundo lugar.

Ejemplo:

  1. DE LA TABLA TEMPORAL

    create table test_timestamp_to_date 
    (date_col date, timestamp_col timestamp(6));
  2. INSERTA:

    insert into test_timestamp_to_date select 
    to_timestamp('11-OCT-2009 2:23:23.793915 PM'),
    to_timestamp('11-OCT-2009 2:23:23.793915 PM')
    from dual;
    
    insert into test_timestamp_to_date select 
    cast(to_timestamp('11-OCT-2009 2:23:23.793915 PM') as date),
    to_timestamp('11-OCT-2009 2:23:23.793915 PM')
    from dual;
  3. RESULTADOS:

    1* select to_char(date_col,'DD-MON-YYYY HH24:MI:SS') date_col, timestamp_col
         from test_timestamp_to_date
    SQL> /
    
    DATE_COL             TIMESTAMP_COL
    -------------------- ----------------------------
    11-OCT-2009 14:23:23 11-OCT-09 02.23.23.793915 PM
    11-OCT-2009 14:23:24 11-OCT-09 02.23.23.793915 PM

Pregunta

¿Hay alguna forma fácil de evitar el redondeo de milisegundos, mientras que el uso de YESO?
Y no estoy hablando acerca de la utilización de TO_CHAR, TO_DATE combinación con un determinado formato; ¿hay algo más?
La codificación con el ELENCO ya está hecho, pero tengo una muy fácil solución.

  • Gracias por la respuesta, sin Embargo,es obvio que la FECHA data_type no tiene las fracciones de segundos. Creo que mi pregunta era acerca de SI alguien sabe ¿por QUÉ ORACLE realizar la conversión de fecha a FECHA diferente cuando lo hace «por defecto» (inserte en la fecha seleccione fecha y hora) de donde la fractionals es simplemente abandonado (incluso si milisegundos 0.999999), en comparación con función de conversión donde fractionals se redondearon al segundo siguiente (si milisegundos son más de 0,5 segundos) o a la anterior, la segunda (si milisegundos son menos de 0,5 segundos). Lo siento si no fui clara sobre el tema. Gracias
  • Y también quería saber si alguien sabe una manera fácil de evitar este redondeo cuando se usa CAST Gracias.
InformationsquelleAutor Serg | 2009-11-11

2 Comentarios

  1. 4

    A quien esté interesado.
    Yo sólo lo imaginé.

    Hay un error en ORACLE función de conversión que hace que se comporte de manera diferente cuando se usa CAST en SQL comparación con el uso de YESO en PL/SQL.

    La función de conversión Erróneamente RONDAS fractionals en SQL y Correctamente TRUNCA en PL/SQL.

    Como vemos el código PL/SQL se comporta de la misma forma que el «defecto» de conversión (inserte en la fecha seleccione fecha y hora) lo que significa que «por defecto» de la conversión está trabajando bien.

    Se ha corregido el error en 11gR2 y hay un parche disponible para 10g.

    SQL del molde debe (y después el parche) TRUNCAR la fractionals en lugar de REDONDEO ellos.

    Gracias.

  2. 2

    ¿Hay alguna forma fácil de evitar el redondeo de milisegundos, mientras que el uso de YESO?

    No, el FECHA tipo de datos no tienen las fracciones de segundos. No significa que dentro de sólo el tipo de datos que adaptarse a lo que estás preguntando.

    • Gracias por la respuesta, sin Embargo,es obvio que la FECHA data_type no tiene las fracciones de segundos. Creo que mi pregunta era acerca de SI alguien sabe ¿por QUÉ ORACLE realizar la conversión de fecha a FECHA diferente cuando lo hace «por defecto» (inserte en la fecha seleccione fecha y hora) de donde la fractionals es simplemente abandonado (incluso si milisegundos 0.999999), en comparación con función de conversión donde fractionals se redondearon al segundo siguiente (si milisegundos son más de 0,5 segundos) o a la anterior, la segunda (si milisegundos son menos de 0,5 segundos). Lo siento si no fui clara sobre el tema. Gracias
    • Y también quería saber si alguien sabe una manera fácil de evitar este redondeo cuando se usa CAST Gracias.

Dejar respuesta

Please enter your comment!
Please enter your name here