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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e686c2c95beefb1c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Inserting Calendar.Time in a database Date: Fri, 6 Aug 2004 09:48:00 +0200 Message-ID: <1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de CN9TOnqJaweo8YBwYpGzfQFHZhiWX2WCeO359FPkKmFxTeQVg= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:2595 Date: 2004-08-06T09:48:00+02:00 List-Id: On Thu, 5 Aug 2004 21:19:07 +0000 (UTC), Martin Dowie wrote: > Dmitry A. Kazakov wrote: >>> I need to insert some timestamps (type Ada.Calendar.Time) in a >>> database accessed via ODBC using gnade+gnat 3.15p. >>> >>> I've looked for timestamp support in the gnade sources without much >>> luck, I've specially checked the embedded sql support and I haven't >>> found nothing for this purpose. >>> >>> I'm completely clueless about the ODBC client packages so if someone >>> has done this before (with gesql or directly), a quick pointer for >>> the things to look at would be great. >> >> The problem is that Ada.Calendar.Time is a political time, while >> persistent time stamps should be UTC or any other absolute time. I >> know no OS-independent solution for that. Then quite often one need to pass time stamps across partitions distributed over different time zones. Presently it is very painful. > Ada.Calendar.Time_Zones might be of use to you. You could store > the value as a string (Ada.Calendar.Formatting). > > See http://www.martin.dowie.btinternet.co.uk/ I see a problem with it. UTC_Time_Offset is not constant, so there also should be an atomic way to get exact UTC. Actually Ada.Real_Time.Time seems a better candidate for UTC. I would add it there. Then why not to provide a numeric type to be a FILETIME equivalent (64-bit value representing the number of 100-nanosecond intervals since January 1, 1601)? Alternatively one could define a full-blown UTC_Time type synchronized with Ada.Real_Time.Time. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de