FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Pues basicamente, diria que tu problema describe la solucion: No la hay (universal).
Si tu función supuestamente genera un formato ISO definido, entonces lo logico es que te apegues a eso. Si firebird o lo que sea se ha desviado, es otro tema. Cada motor, ademas, tiene su forma "especial" de tratar con las fechas (siendo el tipo de datos de los nada-estandar que hay). Esto es lo que hago yo, en base a los multiples lenguajes y motores de BD que me ha tocado manejar. 1- Me estandarice en manejar (de lo posible) solo el formato ISO de fechas. Ademas, todo lo hago, de ser posible, en localizacion USA (decimales son . por ej). Para ello, hago uso por ejemplo en Sql Server de comandos como SET DATEFORMAT si me conecto de forma ad-hoc o de ser posible, especifico en la cadena de conexion o inicio de sesion contra la BD que en "locale" es EN-US, y que las cadenas son UTF-8 2- Intento, a lo máximo, pasar lo mas pronto posible a un tipo de datos correcto, en vez de estar pasando cadenas libres. Osea, si tengo una cadena "12 abr" en la primera "entrada" la paso a Datetime y solo la convierto en la ultima "salida". Osea, intento que en el programa, internamente, exista solo una representacion inflexible y definida de los datos, donde el "locale" del equipo es solo algo que se toma en cuenta para conversiones y para visualizar en el mundo "externo" a ese programa, pero todo en su "interior" esta claro que es un locale fijo (en mi caso, Ingles-US). Eso se desprende de este principio: http://en.wikipedia.org/wiki/Robustness_principle Cita:
Me cabrea del todo si existe una función, que si le pido la fecha en formato cadena, me devuelva algo diferente en base al entorno, idioma, version, presión atmosferica, dirección del viento y fase de la luna. Me la volaria aun mas si tal función parece que sigue un estándar, pero al mirarlo a fondo, resulta que no. Es mejor entonces, que tal función retorne algo fijo e inflexible y que el programador ajuste las cosas o haga su propia función para adaptarse al entorno o las necesidades especificas que enfrente. Y por ultimo, es mejor mandar valores a las BD usando la función params, en vez de mandar como texto los valores y esperar que el programador sepa que es una injeccion sql y todo eso.
__________________
El malabarista. |
#2
|
||||
|
||||
Muchas gracias por sus respuestas, Antonio y Mario.
Cita:
Firebird 1.5 no acepta una sentencia como: debido a la forma en que está expresada esa fecha (error "conversion error from string..."). En cambio no tiene problemas si tan sólo cambio la T por un espacio:
Por lo visto SQLite admite las dos formas. Para salir de dudas respecto a Firebird, sería bueno verificar si alguna de sus más recientes versiones admite la letra "T". Por otro lado, ¿podrían por favor probar unas simples sentencias Select como las anteriores en otros motores? (cambiando TimeStamp o RDB$Database por lo que fuera necesario). Sería muy bueno encontrar cuál es el patrón común, aunque ya de inicio se sepa que no será universal. |
#3
|
||||
|
||||
En la versión 2.5 de Firebird sigue dando ese error. si cambio la "T" por un espacio, funciona correctamente.
Saludos |
#4
|
|||
|
|||
Saludos.
En Oracle usando la función to_date no me reconoce el formato con T.
El formato 1 funciona correctamente, el 2 devuelve un error "date format not recognized", el 3 funciona remplazando la letra T por un espacio ' ' quedando igual al formato 1. Oracle docs date format. |
#5
|
||||
|
||||
Muchas gracias, ElKurgan y beginner01.
Por lo visto la persistencia de Firebird en usar espacio y no una T, tiene que ver con su apego al estándar SQL más que al estándar ISO. No es que se haya "desviado" o algo así. Según se colige, si bien Oracle acepta el formato sin la T, es porque uno mismo tiene que indicárselo como segundo argumento de la función to_date. He leído que el parámetro de formato puede omitirse, pero entonces la función to_date de Oracle se basaría en algo llamado NLS_TERRITORY o NLS_DATE_FORMAT: Cita:
Los animo a hacer más pruebas con los servidores de bases de datos que tengan instalados.
¿Podrían ayudarme a determinar si el formato que acepta Firebird (yyyy-mm-dd hh:mm:ss) podría ser un buen default para la mayoría de los más populares motores SQL? ¿Hay o no un acomodo relativamente común o que merezca cierto respeto del año, mes, día, hora, minuto y segundo al expresar una fecha y hora literalmente en los diversos motores de bases de datos? Por lo que voy viendo, creo que podríamos llegar a tener dos funciones: ghISODateTime (con la T) y ghSQLDateTime (con espacio), pero es muy pronto para decidir. Es necesario recabar más información. NOTA: En el primer mensaje escribí "hh:nn:ss" y más tarde "hh:mm:ss", lo primero fue por compatibilidad con la función FormatDateTime de Delphi, pero este formato del formato no tiene importancia (sabemos que la parte cambiada se refiere a minutos). El formato de un valor literal de fecha y hora es el que importa. Insisto, ¿cuál es el más aceptado o que debiera respetarse? Siéntanse partícipes de estas historias de colaboración. No estoy pidiendo ayuda para un proyecto personal que vaya a entregar a un cliente y por el cual me vayan a pagar. Esta es sólo una pequeña traba de diseño / concepto que vale la pena resolver en nuestra biblioteca, solución que cuando menos servirá a otras personas que busquen respuesta a las mismas inquietudes. Saludos. |
#6
|
|||
|
|||
#7
|
||||
|
||||
Que bien, ¿y sin usar Cast? Digamos, como en la última sentencia que puse (la del Where).
|
#8
|
||||
|
||||
Cita:
Resultado correcto Saludos |
#9
|
||||
|
||||
Después de algunas horas de búsqueda y lectura, pongo una serie de enlaces Web que me parecen relevantes para todos aquellos que se interesen en el tema de los formatos usados en expresiones literales de fecha y hora dentro del lenguaje SQL. Algunos de estos enlaces ya aparecen en mensajes anteriores, no llevan un orden específico.
http://docs.oracle.com/cd/B19306_01/...nctions183.htm http://www.sqlite.org/lang_datefunc.html http://msdn.microsoft.com/es-es/library/ms189491.aspx http://en.wikipedia.org/wiki/ISO_860...epresentations http://www.ibphoenix.com/resources/d...design/doc_169 http://publib.boulder.ibm.com/infoce...c/esqlc126.htm http://msdn.microsoft.com/en-us/library/ms187819.aspx http://msdn.microsoft.com/en-us/libr...#ISO8601Format http://www.sql.org/sql-database/post...-datetime.html http://publib.boulder.ibm.com/infoce...2Fr0008474.htm http://www.firebirdsql.org/en/firebird-date-literals/ http://wiki.navicat.com/wiki/index.p...TIME_format%3F Estaría bien que algunos de los compañeros se tomaran un poco de tiempo para leerlos (parcial o totalmente) y contrastar opiniones. De mi parte tengo ya algunas ideas que podrían ser concluyentes, pero ahora mismo debo ausentarme. Espero haya más retroalimentación. Ah, si alguien tuviera la suerte de encontrar el estándar "oficial" SQL que hable sobre los formatos de cadenas literales de fecha y hora, estaría excelente. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Ayuda sobre manejo de fechas | francodelphi | Conexión con bases de datos | 12 | 27-10-2011 01:22:15 |
Como definir Funciones Globales | destrukthor | Varios | 4 | 07-07-2006 14:12:18 |
Problemas al definir UDF (Funciones en una DLL) | pcicom | Firebird e Interbase | 2 | 21-06-2006 05:49:15 |
Definir funciones y procedimientos en FastReport???? | burasu | Impresión | 1 | 16-05-2005 21:47:37 |
Sobre actualizaciones de programas y estándar x2 | obiwuan | Humor | 0 | 06-05-2003 22:04:07 |
|