Solicito ayuda para definir funciones sobre estándar de fechas ISO o SQL

[[Al González]]

Empezado por Al González

¿Renombramos la función ghISODateTime por ghSQLDateTime?

Empezado por ElKurgan

Sip

Bien, pero entonces creo que mejor sería contar con funciones para ambos tipos de formato:

1. ISO, con la famosa "T" entre la fecha y la hora, e invariable.
2. SQL, sin la "T", pero "configurable" mediante variable global, dado el frágil consenso que hay entre los distintos fabricantes.

Y aquellas otras funciones relacionadas con SQL que necesiten convertir una fecha y hora a expresión literal usarían la opción #2. El programador, entonces, dependiendo del motor que use y la configuración de éste, ajustaría la variable global de formato según se requiera. Aunque, de entrada, el valor predeterminado de dicha variable sería 'yyyy-mm-dd hh:nn:ss' ("nn" es para minutos en Delphi), por ser el formato que todos los motores "deberían" aceptar incondicionalmente.

Veo que se respondió muy poco a las preguntas que he hecho a lo largo del hilo. ¿Tan aburrida es esta sección?

[mamcx]

Empezado por Al González

El programador, entonces, dependiendo del motor que use y la configuración de éste, ajustaría la variable global de formato según se requiera

Lo que implica que tal vez no este usando el estándar ISO.

Lo que estas pensando no tiene sentido. O mejor dicho, es una aberración (y demuestra porque nombrar cosas es una de las dos cosas mas dificiles).

Dices que quieres tener una funcion que devuelve la fecha en estandar ISO.

Eso solo tiene un sentido: Devuelve una cadena en estándar ISO y eso es todo.

Luego, resulta que por la razon que sea, X sistema tiene algo que se parece al estándar ISO. Entonces deberías mandarle la cadena que SI ES el estándar ISO? NO! Porque no lo es.

Y deberías "configurar" la función para que devuelva algo parecido al ISO? NO. Porque la función dice que se llama "devolver cadena estándar ISO". Es algo muy preciso.

-- Eso lo tienes claro. Solo recalco.

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.

Asi que al punto al que voy es que los nombres deben ser precisos en su intención. "FormatDateAsISO" es un nombre preciso. "FormatDate(FormatString:String)" tambien (denota que es ambiguo y se configura con FormatString). "FormatDateAsFirebird" es algo preciso.

La patada es hacer algo como "FormatDateAsSql" -esta es la aberracion a la que hablo- porque resulta que eso depende de cada motor, pero da la idea que me formatea correctamente como "sql" lo cual, en si, es una suposición *erronea*. Entonces para corregirla tocaria hacer algo como "FormatDateAsSql(Engine:TDBEngine)" y no se si quieres ponerte a hacer la implementacion pa cada motor.

Pero es aun peor. Resulta que muchos programadores (que de por si, al mandar fechas como cadenas ya es un error) mandan la fecha de acuerdo al "locale" de sistema operativo (que puede diferir del de la BD)... son como 3 "locales" diferentes en juego: Lo que dice tu funcion, lo que dice el OS, lo que dice la BD (ah, y lo que cree el programador, que no ha pensado en esto).

Lo correcto, como creador de libreria, es dar solo funciones *precisas* y funciones configurables -pero desligadas, osea, agnosticas-, pero cuidarse de interpretar las intenciones y entornos donde operan. Si el programador X maneja un motor Y, en un "locale" Z y necesita una cadena formateada, es EL el que debe crear "FormatDateForDBX", no la libreria (a menos que, sea la libreria "DBXLibrary", osea, sea para ese motor en especifico - si es que el engine tiene un formato "fijo" independiente del locale).

Y usar una vble global es un error (las vbles globales son en el 99.99% de los casos un error de diseño).

[[Al González]]

Agradezco la buena intención, Mario. Vamos por partes para tratar de sintonizarnos.

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.

Empezado por mamcx

[...] ( y demuestra porque nombrar cosas es una de las dos cosas mas dificiles)

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).

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".

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.

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).

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).

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.

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.

[Casimiro Notevi]

Empezado por Al González

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.

No había visto ese hilo, es corto, conciso y claro: las variables globales se usan cuando hacen falta.
En cierto trabajo que estuve hace un tiempo presumían de no usar variables globales, era el gran secreto del programador jefe de allí, "bien, y entonces cómo hacéis?, pregunté, y la respuesta: usamos un record accesible a todos los módulos. ¿Y eso no es lo mismo que una variable global?
Perdón por desvirtuar un poco.

[[Al González]]

Empezado por Casimiro Notevi

Perdón por desvirtuar un poco.

No desvirtúas nada, Antonio. GHF, como la propia VCL, emplea variables globales para algunas cosas.

Bueno, sigamos avanzando en esto.

Propuesta

Por un lado tendremos las funciones ISO ghISODate, ghISOTime y ghISODateTime, que usarán invariablemente el formato extendido de representación completa para fecha del calendario y hora local dado por el estándar ISO 8601; mirar estas tablas. Las funciones ghISOXXX serán útiles donde quiera que se necesite expresar fechas y horas bajo ese formato, como es el caso de los documentos XML:

  <xs:attribute name="fecha" use="required">
    <xs:annotation>
      <xs:documentation>Atributo requerido para la expresión de la fecha y hora de expedición del
        comprobante fiscal. Se expresa en la forma aaaa-mm-ddThh:mm:ss, de acuerdo con la
        especificación ISO 8601.</xs:documentation> 
    </xs:annotation>
    <xs:simpleType>
      <xs:restriction base="xs:dateTime">
        <xs:whiteSpace value="collapse" /> 
      </xs:restriction>
    </xs:simpleType>
  </xs:attribute>
----------
<cfdi:Comprobante xmlns:cfdi="http://www.sat.gob.mx/cfd/3" xmlns:xsi="http://www.w3.org
  /2001/XMLSchema-instance" xsi:schemaLocation="http://www.sat.gob.mx/cfd/3 http://www.sat.gob.mx
  /sitio_internet/cfd/3/cfdv3.xsd http://www.sat.gob.mx/TimbreFiscalDigital TimbreFiscalDigital.xsd"
  version="3.0" folio="4009" fecha="2011-11-14T09:21:00" [...]

Por otra parte estarán las funciones "SQL" relacionadas de la siguiente manera ("->" significa que la función de la izquierda llama a la función de la derecha):

Código Delphi [-]
ghCommaSQLValues -> ghSQLValues -> ghSQLValue -> ghQuotedSQLDate -> ghSQLDate
                                         |--- -> ghQuotedSQLTime -> ghSQLTime
                                         |--- -> ghQuotedSQLDateTime -> ghSQLDateTime

Las tres últimas, ghSQLDate, ghSQLTime y ghSQLDateTime serán "configurables" mediante tres variables globales de tipo String: GHSQLDateFormat, GHSQLTimeFormat, y GHSQLDateTimeFormat, cuyos valores predeterminados serán 'yyyy-mm-dd', 'hh:nn:ss' y 'yyyy-mm-dd hh:nn:ss' (espacio intermedio y no T), respectivamente. No porque sean los que Firebird acepta incondicionalmente, sino porque todos los motores SQL debieran admitirlo sin protestar, ¿me ayudan por favor a corroborar o refutar esta última afirmación?

Si quisiéramos prescindir de las variables globales, habría que declarar parámetros de formato para fechas y horas en todas las funciones del diagrama anterior. Eso sería engorroso y la aplicación consumiría un poco más de recursos, además de que llamar a tales funciones con valores de fecha y hora, y hacerlo con formatos distintos a los del estándar SQL, sería probablemente lo menos frecuente.

¿Vamos bien?

[mamcx]

Empezado por Al González

sino porque todos los motores SQL debieran admitirlo sin protestar, ¿me ayudan por favor a corroborar o refutar esta última afirmación?

Teoricamente si, porque ese formato encaja con el "locale" de USA (en-US) y el formato de 24h. El problema es el separador. Creo que "/" es mas comun que "-" y otros.

------

PD: Segun http://www.postgresql.org/docs/9.1/s...-datetime.html

The output format of the date/time types can be set to one of the four styles ISO 8601, SQL (Ingres), traditional POSTGRES (Unix date format), or German. The default is the ISO format. (The SQL standard requires the use of the ISO 8601 format. The name of the "SQL" output format is a historical accident.) Table 8-14 shows examples of each output style. The output of the date and time types is of course only the date or time part in accordance with the given examples.

ISO	ISO 8601/SQL standard	1997-12-17 07:37:16-08
SQL	traditional style	12/17/1997 07:37:16.00 PST
POSTGRES	original style	Wed Dec 17 07:37:16 1997 PST
German	regional style	17.12.1997 07:37:16.00 PST

Segun ese doc, parece que si es "/" es considerado el estilo "SQL" y si es "-" el ISO.

Con respecto a probar cada estilo en BD, lo que yo hago es que lo defino con comandos como SET DATEFORMAT o su similar. Cuando el motor no tiene algo asi (ej: FoxPro) uso una funcion (ej: Date(2003,1,1) y en el *peor* de los casos el formato de acuerdo al locale de la BD.

El punto que no deje claro antes y que ahora por fin lo logro articular (y que se desprende del principio de la robustes) es que si la cadena de fecha es una "salida" se puede definir el formato que mejor parezca (ya sea el ISO, si es pa pasar entre programas, y el "SQL" para mostrar a humanos) pero en este caso de uso en particular se envia como una "entrada" y por lo tanto, no se puede garantizar que vaya a funcionar, en *todos* los motores. En los motores principales (Sql Server, Postgres, MySql) va a funcionar (ya chequee los docs).


Osea, en resumen... dejalo asi como lo has pensado..

[[Al González]]

Acabo de subir la actualización de abril (archivo GHFreebrary_Delphi7_20130419.zip) con los cambios que aquí se trataron. Todo lo concerniente al tema de este hilo quedó resuelto dentro de la unidad GHFRTL.pas. Siéntanse con la libertad de examinarla, aprovecharla y compartir sus opiniones.

Un agradecimiento a beginner01, ElKurgan, mamcx y Casimiro Notevi.

Sigamos avanzando en los otros temas.

Al González.