Agradezco la
buena intención, Mario. Vamos por partes para tratar de sintonizarnos.
Cita:
Empezado por mamcx
Lo que implica que tal vez no este usando el estándar ISO.
|
"Tal vez" no, ¡con toda seguridad! Ha quedado claro que una cosa es el
estándar ISO para fechas y horas y otra el presunto estándar SQL para fechas y horas (sería bueno encontrar la prueba definitiva de su existencia). Los cuales, hace algunos años, asumí de forma errónea que se trataban de la misma cosa, y por eso nombré a esas funciones con la palabra "ISO", empleándolas luego en asuntos de SQL.
Cita:
Empezado por mamcx
|
Y que lo digas, ese Phil Karlton sabía por lo que hemos pasado algunos "quisquillosos" (horas consultando páginas de código, bibliotecas nativas y de terceros, ayuda de Delphi, diccionarios, gramática del inglés...todo para saber qué nombre darle a una simple clase, método o función).
Cita:
Empezado por mamcx
Dices que quieres tener una funcion que devuelve la fecha en estandar ISO [...] Devuelve una cadena en estándar ISO y eso es todo.
|
Claro, eso no tiene vuelta de hoja, es así de simple y no representa ningún problema. Y las nuevas funciones ghISOXXX ya no serían utilizadas para aspectos de SQL, sino las funciones que lleven la palabra "SQL" en el nombre. Éstas son las que particularmente requieren atención ahora, dado el
descubrimiento "Fecha ISO <> fecha SQL".
Cita:
Empezado por mamcx
Y tener una función que formatea de forma diferente de acuerdo a como lo diga el programador, se llama "Format Date". Que tiene un carajo que ver con que sea el ISO.
|
Si el último enunciado fue una pregunta, la respuesta es: nada. Como dije antes, lo de
ISO queda apartado.
La función que refieres, la nativa
FormatDateTime de Delphi, toma como primer argumento el formato que se quiere utilizar. Pero otras funciones nativas, como DateToStr, TimeToStr y DateTimeToStr (las versiones que reciben un sólo parámetro) no. Todas estas hacen la conversión con base en el formato que señalan un grupo de variables globales. Es algo de lo más normal y a nadie le hace poner el grito en el cielo, en virtud de que dicho formato es relativamente estable bajo su contexto (en nuestro caso sería el contexto del lenguaje SQL), pero siempre está abierto a que la aplicación lo establezca. Tú mismo has dicho que usas el comando
Set DateFormat de MS-SQL.
Cita:
Empezado por mamcx
Asi que al punto al que voy es que los nombres deben ser precisos en su intención.
|
De acuerdo, pero sin caer en la trampa de la
precisión papista (
DeleteASpecifiedFileFromTheContainerDrive para una función que se entiende sencillamente como
DeleteFile).
Cita:
Empezado por mamcx
La patada es hacer algo como "FormatDateAsSql" -esta es la aberracion a la que hablo- porque resulta que eso depende de cada motor [...]
|
No estoy de acuerdo. Según las pruebas y los enlaces que están ante ti, parecen ser varios los motores que se adhieren al misterioso estándar, si bien son pocos los casos que hemos comprobado hasta el momento.
Vamos Mario, arrima el hombro más allá de la crítica (ésta no dejes de soltarla porque la considero importante).
Casimiro,
ElKurgan y
beginner01 se tomaron la molestia de hacer pruebas e indagar. He leído que trabajas con muy diversas tecnologías, por lo que es probable que tengas acceso inmediato a SGBDs no evaluados aún. Si lees con detenimiento, comprenderás que hay indicios sobre la existencia de ese estándar SQL para expresión literal de fechas y horas. Y si es un estándar, ¿por qué no habría de ser el valor predeterminado (
default) de la variable global de formato? A fin de cuentas, sólo tendrían que ajustar esta variable aquellos que usen gestores SQL "renegados" (y mira que MS-SQL, por lo que se ve en los enlaces y en las pruebas, ha terminado admitiendo el formato sin la
T).
Cita:
Empezado por mamcx
[...] que de por si, al mandar fechas como cadenas ya es un error [...]
|
Esa manía de lanzar aventuradas generalizaciones...
Recuerda que hablamos de una biblioteca de propósito general. No voy a suprimir la existencia de una función sólo porque alguien podría darle un mal uso (¿que se dejen de fabricar cuchillos para evitar los apuñalamientos?). Como programadores bibliotecarios, no podemos conocer el total de las situaciones donde una rutina o clase podría ser útil, porque eso está en el infinito. Pero sí podemos, y debemos, abrirnos a la experiencia, al estudio de toda clase de temas y al entendimiento de las necesidades de nuestros usuarios (con más ánimo cuando éstos tienen la paciencia de explicarlas a detalle); y entonces considerar escenarios en los que nuestras pequeñas creaciones significarán la solución a algo.
Nunca sabes quién estará, por ejemplo, creando una herramienta de administración de bases de datos con capacidad para formar sentencias SQL puras, quizá de mantenimiento, a partir de palabras y valores introducidos en cuadros de texto. Ninguna inyección (
no "injeccion") SQL por la que tengamos que asustarnos.
Cita:
Empezado por mamcx
Y usar una vble global es un error (las vbles globales son en el 99.99% de los casos un error de diseño).
|
Creí que ya se había extinto esa corriente de pensamiento que, más por berrinche que por otra cosa, estigmatiza el uso de variables globales. Me hiciste recordar este
viejo hilo (perdonar mis resabios de hace nueve años). Probablemente, para quienes se obstinan en ello, las decenas (quizá cientos) de variables globales nativas de Delphi son el otro 0.01%.
¿Qué es una variable global? Es un
campo de una
clase anónima cuyo contexto es la aplicación entera.
Saludos.