Re: GWindows Database time type

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Stephen Leake wrote:

> Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>>On another front - the proposed bug list. I have an item for it.
>>This might be described as a restriction rather than a bug; this is in
>>GWindows.Databases. I was using one of the Field_Value functions to
>>get a SQL Server datetime value into a variable of type Time (as
>>defined in Ada.Calendar).  The problem is that the range of dates that
>>can be expressed with a variable of type Time is too narrow, and one
>>of the GNATCOM routines which converts the date extracted from SQL
>>Server into a Time choked on a date with a year before 1901.
>>
>>GNATCOM and GWindows need a calendar package similar to Ada.Calendar
>>which is based on a native Windows time representation.
> 
> Native Windows might be the wrong choice; databases are hosted on many
> operating systems, and GWindows should be able to provide clients for
> any of them, possibly thru ODBC.
> 
> Here's a fragment from the MySQL manual
> (http://dev.mysql.com/doc/mysql/en/TIME.html):
> 
> MySQL retrieves and displays TIME values in 'HH:MM:SS' format (or
> 'HHH:MM:SS' format for large hours values). TIME values may range from
> '-838:59:59' to '838:59:59'.

I think MySQL now allows you to make time and dates stricter
through some configuration options (I am personally not surprised
that they've received requests for this). My APQ binding had
to deal with the fact that the newer versions of MySQL seem to
return dates in the "YYYYMMDDHHMMSS" format as a number. This
is different than the SQL standard "YYYY-MM-DD HH:MM:SS" format.
But APQ-2.2 now adjusts for this.

Slightly-OT and Shameless Plug:

I only note this because APQ is designed to shield the application
designer from some of these ugly differences. APQ-2.2 isn't quite
out yet, but it is coming. I think I have spent more time revising
the documentation, then I did on revising the code (whew). But
the end result will be worth it, since it is now much more readable,
and corrects a number of other gross problems that existed in the
last manual. The biggest change is the manual now documents all
API's in "code boxes" in Ada code, rather than as parameters in
a table. This should make it immediately much more readable.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg