* Inserting Calendar.Time in a database @ 2004-08-05 13:44 Jano 2004-08-05 15:21 ` Dmitry A. Kazakov 0 siblings, 1 reply; 41+ messages in thread From: Jano @ 2004-08-05 13:44 UTC (permalink / raw) Hello, 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. Thanks, -- ------------------------- Jano 402450.at.cepsz.unizar.es ------------------------- ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-05 13:44 Inserting Calendar.Time in a database Jano @ 2004-08-05 15:21 ` Dmitry A. Kazakov 2004-08-05 21:19 ` Martin Dowie 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-05 15:21 UTC (permalink / raw) On Thu, 5 Aug 2004 15:44:26 +0200, Jano 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-05 15:21 ` Dmitry A. Kazakov @ 2004-08-05 21:19 ` Martin Dowie 2004-08-06 6:31 ` Jano 2004-08-06 7:48 ` Dmitry A. Kazakov 0 siblings, 2 replies; 41+ messages in thread From: Martin Dowie @ 2004-08-05 21:19 UTC (permalink / raw) 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. 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/ Cheers -- Martin ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-05 21:19 ` Martin Dowie @ 2004-08-06 6:31 ` Jano 2004-08-06 11:32 ` Peter Hermann 2004-08-06 7:48 ` Dmitry A. Kazakov 1 sibling, 1 reply; 41+ messages in thread From: Jano @ 2004-08-06 6:31 UTC (permalink / raw) Martin Dowie dice... > 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. > > Ada.Calendar.Time_Zones might be of use to you. You could store > the value as a string (Ada.Calendar.Formatting). I hadn't thought of time zones and you both are probably right in your concern, but for now this is a secondary worry. This is for local and non-critical use. I simply want to have a timestamp in the database starting from an Ada time type... Currently I'm doing something similar to the Martin suggestion: instead of storing a formatted string, I'm storing the seconds elapsed since an arbitrary epoch. This is a bit clumsy since I can't work with dates if I want to keep the queries indexed. I think I'll move to a two-column-with-trigger-on- insertion setup if no better solution is found. Thanks! ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-06 6:31 ` Jano @ 2004-08-06 11:32 ` Peter Hermann 2004-08-06 11:40 ` Duncan Sands 0 siblings, 1 reply; 41+ messages in thread From: Peter Hermann @ 2004-08-06 11:32 UTC (permalink / raw) Jano <nono@celes.unizar.es> wrote: > non-critical use. I simply want to have a timestamp in the database > starting from an Ada time type... Maybe partially useful for you: http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/calenday.ads -- --Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de --Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen --http://www.csv.ica.uni-stuttgart.de/homes/ph/ --Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-06 11:32 ` Peter Hermann @ 2004-08-06 11:40 ` Duncan Sands 2004-08-08 11:10 ` Jano 0 siblings, 1 reply; 41+ messages in thread From: Duncan Sands @ 2004-08-06 11:40 UTC (permalink / raw) To: comp.lang.ada If you are using GNAT, have a look at GNAT.Calendar and GNAT.Calendar.Time_IO. Ciao, Duncan. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-06 11:40 ` Duncan Sands @ 2004-08-08 11:10 ` Jano 0 siblings, 0 replies; 41+ messages in thread From: Jano @ 2004-08-08 11:10 UTC (permalink / raw) Duncan Sands <baldrick@free.fr> wrote in message news:<mailman.3.1091792465.414.comp.lang.ada@ada-france.org>... > If you are using GNAT, have a look at GNAT.Calendar > and GNAT.Calendar.Time_IO. Pardon me as I see I've not exposed some of my requirements. The timestamp column is used in other SQL queries, and that column to be indexed is extremely interesting. Because of that, I can't afford to transform a string representation or 'seconds-after-epoch' since the index is lost. My database doesn't allow neither to index a view, so that's why the trigger solution is for now the more appealing. Unless, of course, there is a way to insert timestamps with Gnade. I suppose that if I use the thin binding, knowing the internal representation of a sql timestamp as required by the ODBC interface would be enough. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-05 21:19 ` Martin Dowie 2004-08-06 6:31 ` Jano @ 2004-08-06 7:48 ` Dmitry A. Kazakov 2004-08-06 9:28 ` Martin Dowie ` (2 more replies) 1 sibling, 3 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-06 7:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-06 7:48 ` Dmitry A. Kazakov @ 2004-08-06 9:28 ` Martin Dowie 2004-08-06 10:44 ` Dmitry A. Kazakov 2004-08-08 10:46 ` Simon Wright 2004-08-24 19:25 ` Randy Brukardt 2 siblings, 1 reply; 41+ messages in thread From: Martin Dowie @ 2004-08-06 9:28 UTC (permalink / raw) Dmitry A. Kazakov wrote: >> 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. Sorry, not sure what you're getting at here. The UTC_Time_Offset will change due to daylight saving, so it can never be a constant. For Windows, I can't find anything that states if "GetTimeZoneInformation" is atomic or not and this is the routine that returns the time structure. But even if it isn't atomic it's only going to be 'wrong' at most twice a year and only for a second or so each time. Cheers -- Martin ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-06 9:28 ` Martin Dowie @ 2004-08-06 10:44 ` Dmitry A. Kazakov 2004-08-07 9:50 ` Martin Dowie 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-06 10:44 UTC (permalink / raw) On Fri, 6 Aug 2004 10:28:58 +0100, Martin Dowie wrote: > Dmitry A. Kazakov wrote: >>> 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. > > Sorry, not sure what you're getting at here. The UTC_Time_Offset will change > due to daylight saving, so it can never be a constant. > > For Windows, I can't find anything that states if "GetTimeZoneInformation" > is atomic or not and this is the routine that returns the time structure. Under Windows I never would use it to get UTC. I would call QueryPerformanceCounter. Then to convert it to UTC I would use: [periodically + statistical refinement] QueryPerformanceCounter 1 GetSystemTimeAsFileTime QueryPerformanceCounter 2 Mean of 1+2 allows to calculate the offset to UTC epoch. The problem with using GetSystemTimeAsFileTime alone is that it has a very low resolution, so one should use some kind of statistical refinement to get closer to QueryPerformanceCounter accuracy. > But even if it isn't atomic it's only going to be 'wrong' at most twice a > year and only for a second or so each time. Should we shut down the systems for that period of time? (:-)) Then one cannot deal with past and future times. The time zone itself is not constant. Governments are very inventive in making our life harder. Time stamps should be independent on this chaos. So I am not convinced that Ada.Calendar is a proper place for dealing with UTC. Time zones are OK there, no question. But similarity between zone times and UTC is rather apparent. As I said UTC is monotonic, so it should be Ada.Real_Time. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-06 10:44 ` Dmitry A. Kazakov @ 2004-08-07 9:50 ` Martin Dowie 2004-08-07 20:32 ` Dmitry A. Kazakov 0 siblings, 1 reply; 41+ messages in thread From: Martin Dowie @ 2004-08-07 9:50 UTC (permalink / raw) Dmitry A. Kazakov wrote: >> But even if it isn't atomic it's only going to be 'wrong' at most >> twice a year and only for a second or so each time. > > Should we shut down the systems for that period of time? (:-)) Then > one cannot deal with past and future times. The time zone itself is > not constant. Governments are very inventive in making our life > harder. Time stamps should be independent on this chaos. > > So I am not convinced that Ada.Calendar is a proper place for dealing > with UTC. Time zones are OK there, no question. But similarity > between zone times and UTC is rather apparent. As I said UTC is > monotonic, so it should be Ada.Real_Time. Or just read the UTC Offset until you get 2 values that are the same... ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-07 9:50 ` Martin Dowie @ 2004-08-07 20:32 ` Dmitry A. Kazakov 2004-08-08 8:35 ` Martin Dowie 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-07 20:32 UTC (permalink / raw) On Sat, 7 Aug 2004 09:50:18 +0000 (UTC), Martin Dowie wrote: > Or just read the UTC Offset until you get 2 values that are the same... (:-)) Consider an Ada system put in a car moving along a time zone margin... But seriously, there are requirements on time stamps Ada.Calendar.Time does not meet: 1. Not monotonic 2. Coarse granularity (12 ms in the worst case) 3. Two clock readings are not unique And why a small networking embedded system (intelligent sensor, for example), which needs synchronized clock should use Ada.Calendar, maintain time zone data base etc? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-07 20:32 ` Dmitry A. Kazakov @ 2004-08-08 8:35 ` Martin Dowie 2004-08-08 11:03 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Martin Dowie @ 2004-08-08 8:35 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:13x45njobjvn3.yhisk87dws3.dlg@40tude.net... > On Sat, 7 Aug 2004 09:50:18 +0000 (UTC), Martin Dowie wrote: > > > Or just read the UTC Offset until you get 2 values that are the same... > > (:-)) Consider an Ada system put in a car moving along a time zone > margin... > > But seriously, there are requirements on time stamps Ada.Calendar.Time does > not meet: > > 1. Not monotonic It can be monotonic. I'd be a little surprised if it wasn't on implementations that also provided Ada.Real_Time but I'm sure someone will now point to examples where this isn't true ;-) > 2. Coarse granularity (12 ms in the worst case) Yup, that's coarse but then for most implementations Ada.Calendar and Ada.Real_Time are just going to give you what the underlying OS/hardware provide. > 3. Two clock readings are not unique ??? > And why a small networking embedded system (intelligent sensor, for > example), which needs synchronized clock should use Ada.Calendar, maintain > time zone data base etc? I'm sure we could come up with lots of 'little' examples about where this isn't the 'best' solution. But the standard libraries (to me) are there to make the common things easy to do. For 99% (99+%?) these packages will be fine. Cheers -- Martin ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-08 8:35 ` Martin Dowie @ 2004-08-08 11:03 ` Simon Wright 2004-08-09 7:46 ` Dmitry A. Kazakov 2004-08-09 11:52 ` Frank J. Lhota 2 siblings, 0 replies; 41+ messages in thread From: Simon Wright @ 2004-08-08 11:03 UTC (permalink / raw) "Martin Dowie" <martin.dowie@btopenworld.com> writes: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:13x45njobjvn3.yhisk87dws3.dlg@40tude.net... > > But seriously, there are requirements on time stamps Ada.Calendar.Time > does > > not meet: > > > > 1. Not monotonic > > It can be monotonic. I'd be a little surprised if it wasn't on > implementations that also provided Ada.Real_Time but I'm sure > someone will now point to examples where this isn't true ;-) Under VxWorks, certainly for GNAT <= 5.02, Ada.Real_Time.Time is identical to Ada.Calendar.Time (calls clock_gettime()), and you can alter Ada.Calendar.Time using clock_settime(). So what to do if you need to synchronize your clocks over a distributed system? (you understand, this is the problem we had to solve, not a request for help!) -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-08 8:35 ` Martin Dowie 2004-08-08 11:03 ` Simon Wright @ 2004-08-09 7:46 ` Dmitry A. Kazakov 2004-08-09 17:54 ` Nick Roberts 2004-08-09 11:52 ` Frank J. Lhota 2 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-09 7:46 UTC (permalink / raw) On Sun, 8 Aug 2004 08:35:07 +0000 (UTC), Martin Dowie wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:13x45njobjvn3.yhisk87dws3.dlg@40tude.net... >> 3. Two clock readings are not unique >??? It is not warranted that Clock /= Clock. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-09 7:46 ` Dmitry A. Kazakov @ 2004-08-09 17:54 ` Nick Roberts 2004-08-10 7:33 ` Dmitry A. Kazakov 2004-08-10 8:36 ` John B. Matthews 0 siblings, 2 replies; 41+ messages in thread From: Nick Roberts @ 2004-08-09 17:54 UTC (permalink / raw) On Mon, 9 Aug 2004 09:46:20 +0200, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > On Sun, 8 Aug 2004 08:35:07 +0000 (UTC), Martin Dowie wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:13x45njobjvn3.yhisk87dws3.dlg@40tude.net... > >>> 3. Two clock readings are not unique > >> ??? > > It is not warranted that Clock /= Clock. This isn't a spelling flame, but there is a horrible subtlety in the English language here. I'm not certain, but I think the modern interpretation of the word 'warranted' is to mean 'justified'. I think the word 'warranteed' must be used to get the meaning 'guaranteed' (as I assume Dmitry intended). -- Nick Roberts ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-09 17:54 ` Nick Roberts @ 2004-08-10 7:33 ` Dmitry A. Kazakov 2004-08-10 8:36 ` John B. Matthews 1 sibling, 0 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-10 7:33 UTC (permalink / raw) On Mon, 09 Aug 2004 18:54:48 +0100, Nick Roberts wrote: > On Mon, 9 Aug 2004 09:46:20 +0200, Dmitry A. Kazakov > <mailbox@dmitry-kazakov.de> wrote: > >> On Sun, 8 Aug 2004 08:35:07 +0000 (UTC), Martin Dowie wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:13x45njobjvn3.yhisk87dws3.dlg@40tude.net... >> >>>> 3. Two clock readings are not unique >> >>> ??? >> >> It is not warranted that Clock /= Clock. > > This isn't a spelling flame, but there is a horrible subtlety in the > English language here. I was unaware that these words have very different meaning. Thank you for the clarification. > I'm not certain, but I think the modern interpretation of the word > 'warranted' is to mean 'justified'. I think the word 'warranteed' must > be used to get the meaning 'guaranteed' (as I assume Dmitry intended). Yes. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-09 17:54 ` Nick Roberts 2004-08-10 7:33 ` Dmitry A. Kazakov @ 2004-08-10 8:36 ` John B. Matthews 2004-08-10 18:51 ` Nick Roberts 2004-08-19 4:10 ` Jano 1 sibling, 2 replies; 41+ messages in thread From: John B. Matthews @ 2004-08-10 8:36 UTC (permalink / raw) In article <opscg71mkpp4pfvb@bram-2>, "Nick Roberts" <nick.roberts@acm.org> wrote: > On Mon, 9 Aug 2004 09:46:20 +0200, Dmitry A. Kazakov > <mailbox@dmitry-kazakov.de> wrote: > > > On Sun, 8 Aug 2004 08:35:07 +0000 (UTC), Martin Dowie wrote: > > > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > >> news:13x45njobjvn3.yhisk87dws3.dlg@40tude.net... > > > >>> 3. Two clock readings are not unique > > > >> ??? > > > > It is not warranted that Clock /= Clock. > > This isn't a spelling flame, but there is a horrible subtlety in the > English language here. > > I'm not certain, but I think the modern interpretation of the word > 'warranted' is to mean 'justified'. I think the word 'warranteed' must > be used to get the meaning 'guaranteed' (as I assume Dmitry intended). I am unable to verify this usage. Several sources include definitions that mention "written guarantee" and "supported by authority or proof." A "warrantee" is a written guarantee, or the person to whom a warrant or guarantee is given. I am unable to find a definition for the word "warranteed;" it appears to be a term of art in the advertising industry. I would say that Dmitry's usage is correct, if not entirely idiomatic. Does the OP's database support conversion with a format mask? For example, assuming a fuction that converts a Time to a formatted String, tell the database what format to use: DT_String := To_String(Clock); ... insert into <table> values (..., TO_DATE(:DT_String,'YYYY-MM-DD hh:mi:ss'), ...); I understand this is non-portable. John ---- jmatthews at wright dot edu www dot wright dot edu/~john.matthews/ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-10 8:36 ` John B. Matthews @ 2004-08-10 18:51 ` Nick Roberts 2004-08-11 1:14 ` John B. Matthews 2004-08-19 4:10 ` Jano 2004-08-19 4:10 ` Jano 1 sibling, 2 replies; 41+ messages in thread From: Nick Roberts @ 2004-08-10 18:51 UTC (permalink / raw) On Tue, 10 Aug 2004 08:36:44 GMT, John B. Matthews <nospam@nospam.com> wrote: > I am unable to verify this usage. Several sources include > definitions that mention "written guarantee" and "supported by > authority or proof." A "warrantee" is a written guarantee, or > the person to whom a warrant or guarantee is given. I am unable > to find a definition for the word "warranteed;" it appears to be > a term of art in the advertising industry. I would say that > Dmitry's usage is correct, if not entirely idiomatic. Fascinating. (I did say I wasn't sure!) > Does the OP's database support conversion with a format mask? > For example, assuming a fuction that converts a Time to a > formatted String, tell the database what format to use: > > DT_String := To_String(Clock); > ... > insert into <table> values > (..., TO_DATE(:DT_String,'YYYY-MM-DD hh:mi:ss'), ...); > > I understand this is non-portable. Couldn't one simply use: insert into <table> values (..., Current_Timestamp, ...) ? -- Nick Roberts ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-10 18:51 ` Nick Roberts @ 2004-08-11 1:14 ` John B. Matthews 2004-08-19 4:10 ` Jano 1 sibling, 0 replies; 41+ messages in thread From: John B. Matthews @ 2004-08-11 1:14 UTC (permalink / raw) In article <opsci5bhcgp4pfvb@bram-2>, "Nick Roberts" <nick.roberts@acm.org> wrote: > On Tue, 10 Aug 2004 08:36:44 GMT, John B. Matthews <nospam@nospam.com> > wrote: > [...] > > Does the OP's database support conversion with a format mask? > > For example, assuming a fuction that converts a Time to a > > formatted String, tell the database what format to use: > > > > DT_String := To_String(Clock); > > ... > > insert into <table> values > > (..., TO_DATE(:DT_String,'YYYY-MM-DD hh:mi:ss'), ...); > > > > I understand this is non-portable. > > Couldn't one simply use: > > insert into <table> values > (..., Current_Timestamp, ...) > ? Indeed, the ODBC driver's function Current_Timestamp would insert the current server-side timestamp. Unfortunately, the server and client may be in different timezones, leading to Dmitry's original observation about political v. universal time. Also, the OP wanted to know the ODBC driver's vendor-specific timestamp literal format. It's often something like {ts 'yyyy-mm-dd hh:mi:ss'} John ---- jmatthews at wright dot edu www dot wright dot edu/~john.matthews/ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-10 18:51 ` Nick Roberts 2004-08-11 1:14 ` John B. Matthews @ 2004-08-19 4:10 ` Jano 1 sibling, 0 replies; 41+ messages in thread From: Jano @ 2004-08-19 4:10 UTC (permalink / raw) "Nick Roberts" <nick.roberts@acm.org> wrote in message news:<opsci5bhcgp4pfvb@bram-2>... > Couldn't one simply use: > > insert into <table> values > (..., Current_Timestamp, ...) > > ? Yep, but I need several records having the same, exact timestamp, so I can't use the native function directly in several inserts. That's the reason to get the time in the Ada code. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-10 8:36 ` John B. Matthews 2004-08-10 18:51 ` Nick Roberts @ 2004-08-19 4:10 ` Jano 1 sibling, 0 replies; 41+ messages in thread From: Jano @ 2004-08-19 4:10 UTC (permalink / raw) "John B. Matthews" <nospam@nospam.com> wrote in message news:<nospam-91C41E.04421010082004@news-server-fe-01.columbus.rr.com>... > Does the OP's database support conversion with a format mask? > For example, assuming a fuction that converts a Time to a > formatted String, tell the database what format to use: > > DT_String := To_String(Clock); > ... > insert into <table> values > (..., TO_DATE(:DT_String,'YYYY-MM-DD hh:mi:ss'), ...); Thanks for this suggestion, I hadn't thought of it but is probably doable (I'm using Firebird and planning to migrate to Postgresql as soon as the new windows release gets out of beta, and the later for sure have this conversion masks). > I understand this is non-portable. Enough for my needs. Amazing how sometimes the simplest solutions can ellude someone... Thanks! ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-08 8:35 ` Martin Dowie 2004-08-08 11:03 ` Simon Wright 2004-08-09 7:46 ` Dmitry A. Kazakov @ 2004-08-09 11:52 ` Frank J. Lhota 2 siblings, 0 replies; 41+ messages in thread From: Frank J. Lhota @ 2004-08-09 11:52 UTC (permalink / raw) "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:cf4ojq$p4$1@hercules.btinternet.com... > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:13x45njobjvn3.yhisk87dws3.dlg@40tude.net... > It can be monotonic. I'd be a little surprised if it wasn't on > implementations that also provided Ada.Real_Time but I'm sure someone will > now point to examples where this isn't true ;-) To support the Ada.Calendar.Time subprograms Split and Time_Of, Ada.Calendar.Time must basically be an encapsulation of local time. In large parts of the world, however, there are two times of the year when local time itself is not monotic. These are the times where Daylight Savings Time adjustments are done. Part of the rationale behind Ada.Real_Time was to have software that would continue to behave as expected during DST adjustments. Some (but not all) GNAT implementations return basically the same result for Ada.Calendar.Clock and Ada.Real_Time.Clock. We should investigate whether in these implementations, Ada.Real_Time.Clock is monotonic during a DST adjustment. I suspect the answer is no. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-06 7:48 ` Dmitry A. Kazakov 2004-08-06 9:28 ` Martin Dowie @ 2004-08-08 10:46 ` Simon Wright 2004-08-09 8:02 ` Dmitry A. Kazakov 2004-08-24 19:25 ` Randy Brukardt 2 siblings, 1 reply; 41+ messages in thread From: Simon Wright @ 2004-08-08 10:46 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > should be an atomic way to get exact UTC. Actually > Ada.Real_Time.Time seems a better candidate for UTC. I don't see why you would think that? D.8(19): "The Time value I represents the half-open real time interval that starts with E+I*Time_Unit and is limited by E+(I+1)*Time_Unit, where Time_Unit is an implementation-defined real number and E is an unspecified origin point, the epoch, that is the same for all values of the type Time. It is not specified by the language whether the time values are synchronized with any standard time reference. For example, E can correspond to the time of system initialization or it can correspond to the epoch of some time standard." In GNAT Ada.Real_Time.Time is bitwise identical to Ada.Calendar.Time (which I believe to be a mistake, but quite hard to fix). -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-08 10:46 ` Simon Wright @ 2004-08-09 8:02 ` Dmitry A. Kazakov 0 siblings, 0 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-09 8:02 UTC (permalink / raw) On 08 Aug 2004 11:46:34 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> should be an atomic way to get exact UTC. Actually >> Ada.Real_Time.Time seems a better candidate for UTC. > > I don't see why you would think that? I think that it is better to add a child package to Ada.Real_Time. Or else to have Ada.Universal_Time described in the annex E. > D.8(19): > "The Time value I represents the half-open real time interval > that starts with E+I*Time_Unit and is limited by E+(I+1)*Time_Unit, > where Time_Unit is an implementation-defined real number and E is > an unspecified origin point, the epoch, that is the same for all > values of the type Time. It is not specified by the language > whether the time values are synchronized with any standard time > reference. For example, E can correspond to the time of system > initialization or it can correspond to the epoch of some time > standard." So we could add a function, which will give a correspondence between E and UTC epoch. That is for getting UTC. There is of course another problem, how one deals with UTC time stamps? Especially with ones for which there is no corresponding Time value. So I'd prefer a full-blown data type oriented on some international standard. > In GNAT Ada.Real_Time.Time is bitwise identical to Ada.Calendar.Time > (which I believe to be a mistake, but quite hard to fix). Yep, it should be a two-clock system. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-06 7:48 ` Dmitry A. Kazakov 2004-08-06 9:28 ` Martin Dowie 2004-08-08 10:46 ` Simon Wright @ 2004-08-24 19:25 ` Randy Brukardt 2004-08-25 7:24 ` Dmitry A. Kazakov 2 siblings, 1 reply; 41+ messages in thread From: Randy Brukardt @ 2004-08-24 19:25 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net... ... > 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. This is a gross misunderstanding of Ada's clock packages. Ada.Calendar is about time related to an external (standard) timebase, like UTC or CDT. Ada.Real_Time is about time related to an internal timebase. There is no defined relationship between Calendar and Real_Time, and that's intentional. Real_Time would typically be implemented with a hardware counter (such as QueryPerformanceCount on Windows). Moreover, Ada.Real_Time has no concept of dates, which is critical to using a UTC time. Adding all of that to Ada.Real_Time would just make it a clone of Calendar, which then would beg the question of why we need two different time packages. > It is not warranted [guarenteed] that Clock /= Clock. Of course. How could it be? If two calls are sufficiently close together, the clock may not have ticked in the interval. That's true even for Ada.Real_Time.Clock; it only guarantees never to run backwards. Randy. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-24 19:25 ` Randy Brukardt @ 2004-08-25 7:24 ` Dmitry A. Kazakov 2004-08-25 8:18 ` Martin Dowie ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-25 7:24 UTC (permalink / raw) On Tue, 24 Aug 2004 14:25:19 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net... > ... >> 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. > > This is a gross misunderstanding of Ada's clock packages. Ada.Calendar is > about time related to an external (standard) timebase, like UTC or CDT. > Ada.Real_Time is about time related to an internal timebase. There is no > defined relationship between Calendar and Real_Time, and that's intentional. > Real_Time would typically be implemented with a hardware counter (such as > QueryPerformanceCount on Windows). So should UTC clock. The major application area of UTC is time stamping in distributed applications. The requirements on time stamps are very different from of Ada.Calendar.Time. The source of clock synchronization is less important. A pedant would say that the source is always external. Quartz generators are not written in Ada, yet (:-)) It is no matter whether the clock is synchronized with a radio source or an internal quartz. Clock behavior matters. > Moreover, Ada.Real_Time has no concept of dates, which is critical to using > a UTC time. Adding all of that to Ada.Real_Time would just make it a clone > of Calendar, which then would beg the question of why we need two different > time packages. For the same reason we have two of them now. The underlying clocks have different behavior. My point is that the nature of UTC clock is closer to one of real-time than to calendar. >> It is not warranted [guarenteed] that Clock /= Clock. > > Of course. How could it be? If two calls are sufficiently close together, > the clock may not have ticked in the interval. That's true even for > Ada.Real_Time.Clock; it only guarantees never to run backwards. It is a requirement when UTC is used for time stamping. Should Ada.Universal_Time be implemented as a separate package, one could fulfill it. For example, Clock could block until a tick which will change the result. It could be more than one, due to clock synchronization causing ignoring some ticks. Of course Clock should be bounded. Alternatively one could make clock reading artificially by adding "subtick" counter etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-25 7:24 ` Dmitry A. Kazakov @ 2004-08-25 8:18 ` Martin Dowie 2004-08-25 9:25 ` Dmitry A. Kazakov 2004-08-26 0:49 ` Randy Brukardt 2004-08-26 5:22 ` Simon Wright 2 siblings, 1 reply; 41+ messages in thread From: Martin Dowie @ 2004-08-25 8:18 UTC (permalink / raw) Dmitry A. Kazakov wrote: > It is a requirement when UTC is used for time stamping. sounds more like a requierment of your system than of UTC itself to me, i.e. each loggable event must be uniquely tagged. You can always have a suitably faster counter (with a know Fx and usually '0' at power on :-) and then add this to a UTS synchronisation event. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-25 8:18 ` Martin Dowie @ 2004-08-25 9:25 ` Dmitry A. Kazakov 2004-08-25 9:42 ` Martin Dowie 2004-08-26 5:26 ` Simon Wright 0 siblings, 2 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-25 9:25 UTC (permalink / raw) On Wed, 25 Aug 2004 09:18:40 +0100, Martin Dowie wrote: > Dmitry A. Kazakov wrote: >> It is a requirement when UTC is used for time stamping. > > sounds more like a requierment of your system than of UTC itself to me, i.e. > each loggable event must be uniquely tagged. You can always have a suitably > faster counter (with a know Fx and usually '0' at power on :-) and then add > this to a UTS synchronisation event. This works only locally. Consider a distributed data acquisition and control system. You measure some data at physically distinct places. The sensors and actors are interconnected using say Ethernet. Ada is the best candidate for implementing nodes of the system, right? Now, how would you ensure data consistency across the system? A practical example, is a mileage dynamometer. A test runs for weeks. Maximal data frequency is say 1 kHz. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-25 9:25 ` Dmitry A. Kazakov @ 2004-08-25 9:42 ` Martin Dowie 2004-08-26 5:26 ` Simon Wright 1 sibling, 0 replies; 41+ messages in thread From: Martin Dowie @ 2004-08-25 9:42 UTC (permalink / raw) Dmitry A. Kazakov wrote: > This works only locally. Consider a distributed data acquisition and > control system. You measure some data at physically distinct places. > The sensors and actors are interconnected using say Ethernet. Ada is > the best candidate for implementing nodes of the system, right? Now, > how would you ensure data consistency across the system? A practical > example, is a mileage dynamometer. A test runs for weeks. Maximal > data frequency is say 1 kHz. I have seen this on a distributed system (over 1553). You have to do some fancy synchronisation and take errors into account but it can been done. At least to the accuracy required by that system ;-) Cheers -- Martin ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-25 9:25 ` Dmitry A. Kazakov 2004-08-25 9:42 ` Martin Dowie @ 2004-08-26 5:26 ` Simon Wright 1 sibling, 0 replies; 41+ messages in thread From: Simon Wright @ 2004-08-26 5:26 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > This works only locally. Consider a distributed data acquisition and > control system. You measure some data at physically distinct > places. The sensors and actors are interconnected using say > Ethernet. Ada is the best candidate for implementing nodes of the > system, right? Now, how would you ensure data consistency across the > system? A practical example, is a mileage dynamometer. A test runs > for weeks. Maximal data frequency is say 1 kHz. We are meeting this sort of requirement using SNTP as the transport mechanism. The interface to the facility is (on the Ada parts of the system) <project>.Calendar, same features as Ada.Calendar (but you can't use this sort of Time for "delay until", sadly). -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-25 7:24 ` Dmitry A. Kazakov 2004-08-25 8:18 ` Martin Dowie @ 2004-08-26 0:49 ` Randy Brukardt 2004-08-26 9:30 ` Dmitry A. Kazakov 2004-08-26 5:22 ` Simon Wright 2 siblings, 1 reply; 41+ messages in thread From: Randy Brukardt @ 2004-08-26 0:49 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:poqdv57eopmp$.z8pwmifutqaq.dlg@40tude.net... > On Tue, 24 Aug 2004 14:25:19 -0500, Randy Brukardt wrote: > > > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > > news:1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net... > > ... > >> 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. > > > > This is a gross misunderstanding of Ada's clock packages. Ada.Calendar is > > about time related to an external (standard) timebase, like UTC or CDT. > > Ada.Real_Time is about time related to an internal timebase. There is no > > defined relationship between Calendar and Real_Time, and that's intentional. > > Real_Time would typically be implemented with a hardware counter (such as > > QueryPerformanceCount on Windows). > > So should UTC clock. The major application area of UTC is time stamping in > distributed applications. The requirements on time stamps are very > different from of Ada.Calendar.Time. Of course. "Time stamps" actually have nothing to do with time; the only requirement being that they be unique (and in some cases increasing). "Time" is usually used as a quick way to get them, but that is often a mistake (precision issues, time bases, etc.) It would be better to call them "generation stamps" or something like that. Certainly, you can use a UTC time to implement a "generation stamp", but it isn't such a thing, and it makes no sense to imply that it could be. Moreover, we don't want to require a UTC time base in Ada, because embedded systems may not have access to an appropriate time base - and we certainly don't want to insist that every system be hooked up to the Internet! OTOH, UTC time really is about time (that is, years, months, days, hours, minutes, seconds), which makes it exactly appropriate for Ada.Calendar. > The source of clock synchronization is > less important. A pedant would say that the source is always external. > Quartz generators are not written in Ada, yet (:-)) It is no matter whether > the clock is synchronized with a radio source or an internal quartz. Clock > behavior matters. Yes, it matters a lot. Using locally determined UTC time as a generation stamp would be terrible if the systems are not synchronized to the same time base. That immediately takes it out the of realm of what the language can specify. > > Moreover, Ada.Real_Time has no concept of dates, which is critical to using > > a UTC time. Adding all of that to Ada.Real_Time would just make it a clone > > of Calendar, which then would beg the question of why we need two different > > time packages. > > For the same reason we have two of them now. The underlying clocks have > different behavior. My point is that the nature of UTC clock is closer to > one of real-time than to calendar. You've obviously not had to sit thru hours of arguments with Tucker Taft on this topic! One of the implementation models for Ada.Calendar (and one apparently used by SofCheck derived compilers) is that an object of Ada.Calendar.Time is a monotomically increasing clock (usually UTC time). Localization is applied in Split. The reason for the design of the Ada.Calendar.Time_Zones is so that this implementation model can be applied. The important thing to realize here is that there is no *requirement* for the *actual* value of Ada.Calendar.Time to run backwards. There is no real difference in requirements between UTC time and Ada.Calendar.Time. Moreover, there is no requirement that Ada.Calendar.Time even default to local time. I think it would have been best if it in fact was required to be UTC time, but that would not have made sense in 1980 (popular OSes at that time provided no or very weak time zone support), and now we have a compatibility problem. > >> It is not warranted [guarenteed] that Clock /= Clock. > > > > Of course. How could it be? If two calls are sufficiently close together, > > the clock may not have ticked in the interval. That's true even for > > Ada.Real_Time.Clock; it only guarantees never to run backwards. > > It is a requirement when UTC is used for time stamping. Should > Ada.Universal_Time be implemented as a separate package, one could fulfill > it. For example, Clock could block until a tick which will change the > result. It could be more than one, due to clock synchronization causing > ignoring some ticks. Of course Clock should be bounded. Alternatively one > could make clock reading artificially by adding "subtick" counter etc. That's clearly a requirement of your application which has nothing to do with the definition of Time. Your "generation stamp" package should be designed to guarantee this property if it is needed; it's a rare enough requirement that there isn't any reason to build it into the language. Also note that your original complaint is bogus: > I see a problem with it. UTC_Time_Offset is not constant, so there also should be > an atomic way to get exact UTC. There is, you're just doing the operations in the wrong order: declare A_Time : Ada.Calendar.Time := Ada.Calendar.Clock; UTC_Adjustment : Ada.Calendar.Time_Zones.Time_Offset := Ada.Calendar.Time_Zones.UTC_Time_Offset (A_Time); begin -- Do Split or other operations using UTC_Adjustment. end; The point is that you must never save values of UTC_Adjustment, but rather recalculate them each time. Hopefully the implementation of Ada.Calendar.Time_Zones doesn't make this too expensive. Also note that using Tucker's model, you can't apply the adjustment to the time value, rather it only is used in calls to Split or other formatting routines. For use a generation stamp, you'll have to reformat this into something that you can pass around anyway, so that's not a real problem. And it's no problem to encapsulate all of this into a generation stamp package that does the needed conversions under the covers -- the best plan in any case (as you'll need control over the format of the stamps for streaming or whatever -- you don't want this breaking if you move to a different compiler). Randy. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-26 0:49 ` Randy Brukardt @ 2004-08-26 9:30 ` Dmitry A. Kazakov 2004-08-26 10:11 ` Martin Dowie 2004-08-26 18:55 ` Randy Brukardt 0 siblings, 2 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-26 9:30 UTC (permalink / raw) On Wed, 25 Aug 2004 19:49:46 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:poqdv57eopmp$.z8pwmifutqaq.dlg@40tude.net... >> On Tue, 24 Aug 2004 14:25:19 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net... >>> ... >>>> 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. >>> >>> This is a gross misunderstanding of Ada's clock packages. Ada.Calendar > is >>> about time related to an external (standard) timebase, like UTC or CDT. >>> Ada.Real_Time is about time related to an internal timebase. There is no >>> defined relationship between Calendar and Real_Time, and that's > intentional. >>> Real_Time would typically be implemented with a hardware counter (such > as >>> QueryPerformanceCount on Windows). >> >> So should UTC clock. The major application area of UTC is time stamping in >> distributed applications. The requirements on time stamps are very >> different from of Ada.Calendar.Time. > > Of course. "Time stamps" actually have nothing to do with time; the only > requirement being that they be unique (and in some cases increasing). > "Time" is usually used as a quick way to get them, but that is often a mistake > (precision issues, time bases, etc.) It would be better to call them > "generation stamps" or something like that. Certainly, you can use a UTC > time to implement a "generation stamp", but it isn't such a thing, and it > makes no sense to imply that it could be. No. That would be just a stamp. A time stamp identifies the time of object creation. One more typical example: you measure some signal and wish to display it on-line as a wave form on the other side of the globe. Nether measurement points are equidistant, nor something concrete could be said about the communication channel. > Moreover, we don't want to require > a UTC time base in Ada, because embedded systems may not have access to an > appropriate time base - and we certainly don't want to insist that every > system be hooked up to the Internet! It could be a child package. It could be a separate package described in the Annex E. > OTOH, UTC time really is about time (that is, years, months, days, hours, > minutes, seconds), which makes it exactly appropriate for Ada.Calendar. Ada.Real_Time is also about time. That you can view a clock reading as year, month, etc tells nothing about time. It tells only about the time base of the duration interval the clock return. The "system start" base is as good as any other. >> The source of clock synchronization is >> less important. A pedant would say that the source is always external. >> Quartz generators are not written in Ada, yet (:-)) It is no matter >> whether >> the clock is synchronized with a radio source or an internal quartz. Clock >> behavior matters. > > Yes, it matters a lot. Using locally determined UTC time as a generation > stamp would be terrible if the systems are not synchronized to the same time > base. That immediately takes it out the of realm of what the language can > specify. Does Ada.Calendar require that? It is quite legal set year 2090 on my system. Why then Ada.Universal_Time should? We cannot influence the precision of mapping the time base to UTC. So we should not specify it. BTW, quite often the precision required for clock synchronization of nodes is in order of magnitude lower than the required accuracy of clocks. For example you need one second externally and one microsecond locally. Essential is range, resolution and backward jumps. >> For the same reason we have two of them now. The underlying clocks have >> different behavior. My point is that the nature of UTC clock is closer to >> one of real-time than to calendar. > > You've obviously not had to sit thru hours of arguments with Tucker Taft on > this topic! > > One of the implementation models for Ada.Calendar (and one apparently used > by SofCheck derived compilers) is that an object of Ada.Calendar.Time is a > monotomically increasing clock (usually UTC time). Localization is applied > in Split. The reason for the design of the Ada.Calendar.Time_Zones is so > that this implementation model can be applied. The important thing to > realize here is that there is no *requirement* for the *actual* value of > Ada.Calendar.Time to run backwards. There is no real difference in > requirements between UTC time and Ada.Calendar.Time. Moreover, there is no > requirement that Ada.Calendar.Time even default to local time. I think it > would have been best if it in fact was required to be UTC time, but that > would not have made sense in 1980 (popular OSes at that time provided no or > very weak time zone support), and now we have a compatibility problem. Do you want to strengthen Ada.Calendar requirements? >>>> It is not warranted [guarenteed] that Clock /= Clock. >>> >>> Of course. How could it be? If two calls are sufficiently close > together, >>> the clock may not have ticked in the interval. That's true even for >>> Ada.Real_Time.Clock; it only guarantees never to run backwards. >> >> It is a requirement when UTC is used for time stamping. Should >> Ada.Universal_Time be implemented as a separate package, one could fulfill >> it. For example, Clock could block until a tick which will change the >> result. It could be more than one, due to clock synchronization causing >> ignoring some ticks. Of course Clock should be bounded. Alternatively one >> could make clock reading artificially by adding "subtick" counter etc. > > That's clearly a requirement of your application which has nothing to do > with the definition of Time. Your "generation stamp" package should be > designed to guarantee this property if it is needed; it's a rare enough > requirement that there isn't any reason to build it into the language. I do not think so. Application areas are: time stamping, time synchronization in distributed systems, data logging, remote control, remote data acquisition, communication protocols requiring time. > Also note that your original complaint is bogus: > >> I see a problem with it. UTC_Time_Offset is not constant, so there also >> should be an atomic way to get exact UTC. > > There is, you're just doing the operations in the wrong order: > > declare > A_Time : Ada.Calendar.Time := Ada.Calendar.Clock; > UTC_Adjustment : Ada.Calendar.Time_Zones.Time_Offset := > Ada.Calendar.Time_Zones.UTC_Time_Offset (A_Time); > begin > -- Do Split or other operations using UTC_Adjustment. > end; > > The point is that you must never save values of UTC_Adjustment, but rather > recalculate them each time. Hopefully the implementation of > Ada.Calendar.Time_Zones doesn't make this too expensive. So UTC_Time_Offset should remember the local zone time adjusting history and also foresee all future adjustments? How efficient it would be? Say, there are 32 1kHz channels, for each value I need a time stamp. A real-life application should convert Ada...Clock to FILETIME. It would using Split + the formula for leap years, seconds etc, all that in an interrupt handler? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-26 9:30 ` Dmitry A. Kazakov @ 2004-08-26 10:11 ` Martin Dowie 2004-08-26 10:58 ` Dmitry A. Kazakov 2004-08-26 18:55 ` Randy Brukardt 1 sibling, 1 reply; 41+ messages in thread From: Martin Dowie @ 2004-08-26 10:11 UTC (permalink / raw) Dmitry A. Kazakov wrote: > No. That would be just a stamp. A time stamp identifies the time of > object creation. One more typical example: you measure some signal > and wish to display it on-line as a wave form on the other side of > the globe. Nether measurement points are equidistant, nor something > concrete could be said about the communication channel. Er, sorry, that's just not how the word "timestamp" is used either in English or in engineering (at least here in the UK) - it does not need to be tied to UTC or local time or anything other than 'time from reset' (usually). So long as the period between 'ticks' is known then you have all the information you need. It may be that you need to synch several boards but all you need to do is find the relative differences between the different start points (i.e. where each board thought '0' was). > Ada.Real_Time is also about time. That you can view a clock reading as > year, month, etc tells nothing about time. It tells only about the > time base of the duration interval the clock return. The "system > start" base is as good as any other. ...and that's exactly why you don't need UTC! :-) ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-26 10:11 ` Martin Dowie @ 2004-08-26 10:58 ` Dmitry A. Kazakov 2004-08-26 12:32 ` Martin Dowie 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-26 10:58 UTC (permalink / raw) Martin Dowie wrote: > Dmitry A. Kazakov wrote: >> No. That would be just a stamp. A time stamp identifies the time of >> object creation. One more typical example: you measure some signal >> and wish to display it on-line as a wave form on the other side of >> the globe. Nether measurement points are equidistant, nor something >> concrete could be said about the communication channel. > > Er, sorry, that's just not how the word "timestamp" is used either in > English or in engineering (at least here in the UK) - it does not need to > be tied to UTC or local time or anything other than 'time from > reset' (usually). There is no time from reset, because there was no reset. Consider publishers broadcasting data. Well, after all any time scale has its 0, call it reset time, if you want. So what is the point? That the time bias shall be indeterminable? > So long > as the period between 'ticks' is known then you have all the information > you need. Only theoretically, practically the errors will accumulate making the whole system unusable. Note also that some ticks might get lost. Consider a data logger working remotely... > It may be that you need to synch several boards but all you need to do is > find > the relative differences between the different start points (i.e. where > each board thought '0' was). More than that. You have to do it periodically. I.e. you have to synchronize time, no more no less. Now consider that your boards communicate in a many-to-many way. Data have different periods, are event controlled; there are publisher/subscriber issues etc. What you propose is in fact to synchronize time for *each* peer-to-peer connection. Apart from being unrealistic and extremely complex, time/traffic consuming, consider a possiblity that there already exist radio clock devices doing that much better. It is no seller. No real application will do that. It will get UTC from OS in some OS-specific way, as it happens now. >> Ada.Real_Time is also about time. That you can view a clock reading as >> year, month, etc tells nothing about time. It tells only about the >> time base of the duration interval the clock return. The "system >> start" base is as good as any other. > > ...and that's exactly why you don't need UTC! :-) So you actually disagree with Randy! (:-)) -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-26 10:58 ` Dmitry A. Kazakov @ 2004-08-26 12:32 ` Martin Dowie 2004-08-26 16:26 ` Dmitry A. Kazakov 0 siblings, 1 reply; 41+ messages in thread From: Martin Dowie @ 2004-08-26 12:32 UTC (permalink / raw) Dmitry A. Kazakov wrote: > More than that. You have to do it periodically. Absolutely > exist radio clock devices doing that much better. It is no seller. It might be a 'no seller' - but it's already 'flying' ;-) > So you actually disagree with Randy! (:-)) I'm not sure now! ;-) All I'm saying is that for the embedded system I work with, we don't /need/ UTC (and I suspect that's true for a lot of apps). We do need a notion of timestamp but there is no need to actually tie it to UTC or any 'calendar' - it just needs to be from 'reset' for each board. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-26 12:32 ` Martin Dowie @ 2004-08-26 16:26 ` Dmitry A. Kazakov 2004-08-26 17:23 ` Martin Dowie 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-26 16:26 UTC (permalink / raw) On Thu, 26 Aug 2004 13:32:49 +0100, Martin Dowie wrote: > Dmitry A. Kazakov wrote: >> exist radio clock devices doing that much better. It is no seller. > > It might be a 'no seller' - but it's already 'flying' ;-) Concord? (:-)) >> So you actually disagree with Randy! (:-)) > > I'm not sure now! ;-) > > All I'm saying is that for the embedded system I work with, we don't > /need/ UTC (and I suspect that's true for a lot of apps). We do need > a notion of timestamp but there is no need to actually tie it to UTC or > any 'calendar' - it just needs to be from 'reset' for each board. I think it is important for Ada to realize that embedded world is changing. -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-26 16:26 ` Dmitry A. Kazakov @ 2004-08-26 17:23 ` Martin Dowie 0 siblings, 0 replies; 41+ messages in thread From: Martin Dowie @ 2004-08-26 17:23 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Concord? (:-)) Ouch! no! ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-26 9:30 ` Dmitry A. Kazakov 2004-08-26 10:11 ` Martin Dowie @ 2004-08-26 18:55 ` Randy Brukardt 2004-08-26 20:04 ` Dmitry A. Kazakov 1 sibling, 1 reply; 41+ messages in thread From: Randy Brukardt @ 2004-08-26 18:55 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:19pc26q7dwvt2.1fyyqhr5nv5j2$.dlg@40tude.net... ... > > The point is that you must never save values of UTC_Adjustment, but rather > > recalculate them each time. Hopefully the implementation of > > Ada.Calendar.Time_Zones doesn't make this too expensive. > > So UTC_Time_Offset should remember the local zone time adjusting history > and also foresee all future adjustments? How efficient it would be? It's just a system call of some sort, its certainly no worse than calling Clock itself and probably is much better. > Say, there are 32 1kHz channels, for each value I need a time stamp. A real-life > application should convert Ada...Clock to FILETIME. It would using Split + > the formula for leap years, seconds etc, all that in an interrupt handler? The overhead of calling Clock is such that it would not make sense to do this on many existing implementations, even if you use Ada.Real_Time. It certainly would make no sense on any system built on top of Windows or Unix or Linux. The adjustment to the local time isn't a big enough portion of that overhead to matter much. I would expect that it might be possible on some real-time kernels. For those, it's clear that Ada.Calendar.Time should be UTC time, and a child package provided to get the Local_Time_Offset if that is needed. (That really ought to be required behavior of Calendar, but it's simply too incompatible - and in the worst way, at run time - to do.) An alternative (especially in the inprecise requirements that you suggested in your message) is to figure the time base of Ada.Real_Time, then using Real_Time for most operations. Indeed, this is exactly how Calendar is implemented on Janus/Ada and on GNAT for Windows: the system time functions are used to get the time base, and QueryPerformanceCounter is used to get high precision time information within that time base. (Of course, the fact that QueryPerformanceCounter leaps forward many seconds on some hardware is a problem.) We rebase every 5 minutes to avoid drift problems from using two separate clocks; I believe GNAT is similar. In any case, the sorts of requirements that you have are simply not supportable within the standard. (Or implementations, for that matter.) No Ada vendor is going to guarantee anything about the accuracy of the time base (because it's completely out of their control), which is a necessary parameter in any sort of distributed system. Either it doesn't matter much (as in HTTP), or you are going to have to take steps to insure that it is accurate enough, and that requires going beyond anything that the standard could possibly give you. Randy. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-26 18:55 ` Randy Brukardt @ 2004-08-26 20:04 ` Dmitry A. Kazakov 0 siblings, 0 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2004-08-26 20:04 UTC (permalink / raw) Randy Brukardt wrote: > I would expect that it might be possible on some real-time kernels. For > those, it's clear that Ada.Calendar.Time should be UTC time, Agree > and a child > package provided to get the Local_Time_Offset if that is needed. (That > really ought to be required behavior of Calendar, but it's simply too > incompatible - and in the worst way, at run time - to do.) > > An alternative (especially in the inprecise requirements that you > suggested in your message) is to figure the time base of Ada.Real_Time, > then using Real_Time for most operations. Indeed, this is exactly how > Calendar is implemented on Janus/Ada and on GNAT for Windows: the system > time functions are used to get the time base, and QueryPerformanceCounter > is used to get high precision time information within that time base. (Of > course, the fact that QueryPerformanceCounter leaps forward many seconds > on some hardware is a problem.) We rebase every 5 minutes to avoid drift > problems from using two separate clocks; I believe GNAT is similar. But normally it is all that required, no more! Why not to put it the standard? If that cannot be supported on all platforms, then it could be a separate optional package. > In any case, the sorts of requirements that you have are simply not > supportable within the standard. You mean X1 := Clock; X2 := Clock; then X1 < X2? If the *optional* package would be required to have Time at least 64-bit, would then X1 < X2 be such a big burden? > (Or implementations, for that matter.) No > Ada vendor is going to guarantee anything about the accuracy of the time > base (because it's completely out of their control), which is a necessary > parameter in any sort of distributed system. Either it doesn't matter much > (as in HTTP), or you are going to have to take steps to insure that it is > accurate enough, and that requires going beyond anything that the standard > could possibly give you. Absolutely. Time synchronization should be left outside. The standard should only require a reasonable range -200..+200 years from now, fine resolution 1..100 nano, no backward jumps, unique readings for same task. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Inserting Calendar.Time in a database 2004-08-25 7:24 ` Dmitry A. Kazakov 2004-08-25 8:18 ` Martin Dowie 2004-08-26 0:49 ` Randy Brukardt @ 2004-08-26 5:22 ` Simon Wright 2 siblings, 0 replies; 41+ messages in thread From: Simon Wright @ 2004-08-26 5:22 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Tue, 24 Aug 2004 14:25:19 -0500, Randy Brukardt wrote: > > > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > > news:1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net... > > ... > >> 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. > > > > This is a gross misunderstanding of Ada's clock packages. Ada.Calendar is > > about time related to an external (standard) timebase, like UTC or CDT. > > Ada.Real_Time is about time related to an internal timebase. There is no > > defined relationship between Calendar and Real_Time, and that's intentional. > > Real_Time would typically be implemented with a hardware counter (such as > > QueryPerformanceCount on Windows). > > So should UTC clock. The major application area of UTC is time > stamping in distributed applications. The requirements on time > stamps are very different from of Ada.Calendar.Time. The source of > clock synchronization is less important. A pedant would say that the > source is always external. Quartz generators are not written in > Ada, yet (:-)) It is no matter whether the clock is synchronized > with a radio source or an internal quartz. Clock behavior matters. The major application area of Ada.Real_Time is in running real-time systems which is jargon for systems that must meet their deadlines. There is no requirement at all for UTC or anything like that from that part of the embedded market. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2004-08-26 20:04 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-08-05 13:44 Inserting Calendar.Time in a database Jano 2004-08-05 15:21 ` Dmitry A. Kazakov 2004-08-05 21:19 ` Martin Dowie 2004-08-06 6:31 ` Jano 2004-08-06 11:32 ` Peter Hermann 2004-08-06 11:40 ` Duncan Sands 2004-08-08 11:10 ` Jano 2004-08-06 7:48 ` Dmitry A. Kazakov 2004-08-06 9:28 ` Martin Dowie 2004-08-06 10:44 ` Dmitry A. Kazakov 2004-08-07 9:50 ` Martin Dowie 2004-08-07 20:32 ` Dmitry A. Kazakov 2004-08-08 8:35 ` Martin Dowie 2004-08-08 11:03 ` Simon Wright 2004-08-09 7:46 ` Dmitry A. Kazakov 2004-08-09 17:54 ` Nick Roberts 2004-08-10 7:33 ` Dmitry A. Kazakov 2004-08-10 8:36 ` John B. Matthews 2004-08-10 18:51 ` Nick Roberts 2004-08-11 1:14 ` John B. Matthews 2004-08-19 4:10 ` Jano 2004-08-19 4:10 ` Jano 2004-08-09 11:52 ` Frank J. Lhota 2004-08-08 10:46 ` Simon Wright 2004-08-09 8:02 ` Dmitry A. Kazakov 2004-08-24 19:25 ` Randy Brukardt 2004-08-25 7:24 ` Dmitry A. Kazakov 2004-08-25 8:18 ` Martin Dowie 2004-08-25 9:25 ` Dmitry A. Kazakov 2004-08-25 9:42 ` Martin Dowie 2004-08-26 5:26 ` Simon Wright 2004-08-26 0:49 ` Randy Brukardt 2004-08-26 9:30 ` Dmitry A. Kazakov 2004-08-26 10:11 ` Martin Dowie 2004-08-26 10:58 ` Dmitry A. Kazakov 2004-08-26 12:32 ` Martin Dowie 2004-08-26 16:26 ` Dmitry A. Kazakov 2004-08-26 17:23 ` Martin Dowie 2004-08-26 18:55 ` Randy Brukardt 2004-08-26 20:04 ` Dmitry A. Kazakov 2004-08-26 5:22 ` Simon Wright
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox