From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a875d9649dde34e3 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: GWindows Database time type Date: 30 Sep 2004 20:57:16 -0400 Organization: Cuivre, Argent, Or Message-ID: References: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1096592261 85982 212.85.156.195 (1 Oct 2004 00:57:41 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Fri, 1 Oct 2004 00:57:41 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:4476 Date: 2004-09-30T20:57:16-04:00 Fionn mac Cuimhaill writes: > On 29 Sep 2004 20:13:23 -0400, Stephen Leake > wrote: > > >Fionn mac Cuimhaill 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'. > > > >For that, Time needs to be a string; that will always be the most > >general format. > > > It's difficult to do tate arithmetic on strings; Well, yes. But nothing says the type stored in the database has to be the type you use to do date arithmetic. > Windows already has a SYSTEMTIME structure that is used in GNATCOM; > there is also a 64-bit integer representation of time. According to > Microsoft docs, SYSTEMTIME accomodates years all the way back to > 1601. I'm not sure what the 64-bit integer represents. (milliseconds > since Jan 1, 1601???) I think that is the start of the Gregorian calendar, or something like that. > I have no idea of the reason for the 1601 date; in any case, it is a > great improvement over the 1901 limiting date used in Ada.Calendar. > There is no reason why a GWindows.Calendar package couldn't be > created that makes use of the SYSTEMTIME structure and also supports > a date representation usable for date arithmetic. We could, but I would object to calling it Calendar; that's sort of a reserved name in Ada. There are many other, equally good, ways to build a date package. Hmm. I suppose if we accept up front that GWindows is very Win32 based, it's not such a bad name. Windex has a binding to Win32 system time and file time types. > It looks to me like David Botton went with Ada.Calendar because it > was an already existing standard package, which if not perfect, was > at least usable and saved him the time of writing a calendar > package. Yes. The consensus is that each user should write the time/date package they need. For my real-time simulations, I use a 64 bit fixed point time, with a resolution of nanoseconds and a range of 242 years. > The native Windows time formats certainly cover a wide enough range of > dates to work better than Ada.Calendar. There doesn't seem to be any > element of GWindows which actually parses SQL; SQL code is managed > entirely by the programmer, and therefore any dialect of SQL can be > used. It wouldn't be too difficult to create a GWindows.Calendar that > could handle dates from any kind of database. Well, I still don't see why the design of GWindows.Calendar should be at all influenced by databases; let's keep things orthogonal as much as possible. -- -- Stephe