Inserting Calendar.Time in a database

Inserting Calendar.Time in a database

[Jano]

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

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Martin Dowie]

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

Re: Inserting Calendar.Time in a database

[Jano]

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!

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Martin Dowie]

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

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Peter Hermann]

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)

Re: Inserting Calendar.Time in a database

[Duncan Sands]

If you are using GNAT, have a look at GNAT.Calendar
and GNAT.Calendar.Time_IO.

Ciao,

Duncan.

Re: Inserting Calendar.Time in a database

[Martin Dowie]

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

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Martin Dowie]

"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

Re: Inserting Calendar.Time in a database

[Simon Wright]

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

Re: Inserting Calendar.Time in a database

[Simon Wright]

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

Re: Inserting Calendar.Time in a database

[Jano]

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.

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Frank J. Lhota]

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

Re: Inserting Calendar.Time in a database

[Nick Roberts]

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

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[John B. Matthews]

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/

Re: Inserting Calendar.Time in a database

[Nick Roberts]

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

Re: Inserting Calendar.Time in a database

[John B. Matthews]

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/

Re: Inserting Calendar.Time in a database

[Jano]

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

Re: Inserting Calendar.Time in a database

[Jano]

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

Re: Inserting Calendar.Time in a database

[Randy Brukardt]

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

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Martin Dowie]

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.

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Martin Dowie]

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

Re: Inserting Calendar.Time in a database

[Randy Brukardt]

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

Re: Inserting Calendar.Time in a database

[Simon Wright]

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

Re: Inserting Calendar.Time in a database

[Simon Wright]

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

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Martin Dowie]

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! :-)

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Martin Dowie]

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.

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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

Re: Inserting Calendar.Time in a database

[Martin Dowie]

Dmitry A. Kazakov wrote:
> Concord? (:-))

Ouch! no!

Re: Inserting Calendar.Time in a database

[Randy Brukardt]

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

Re: Inserting Calendar.Time in a database

[Dmitry A. Kazakov]

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