Advice on Calendar.Time

Advice on Calendar.Time

[REH]

Ok, I have another problem:

We have functions that convert between our mission time and
Ada.Calendar.Time.  The current implementation depends on the internal
representation of Time.  This is a pain because it must be rewritten
everytime we move to a new compile (or even a new version of the same).
 Is there a way to do this in Standard Ada?  Our mission time is the
number of seconds since an arbitrarily choosen epoch (1/1/1998) GMT.
We originally used Time_Of, but had problems because Time_Of was using
local time and did DST adjustments which were undesirable.

I hope that was clear.

Re: Advice on Calendar.Time

[Larry Kilgallen]

In article <1131465873.702910.143400@g43g2000cwa.googlegroups.com>, "REH" <spamjunk@stny.rr.com> writes:
> Ok, I have another problem:
> 
> We have functions that convert between our mission time and
> Ada.Calendar.Time.  The current implementation depends on the internal
> representation of Time.  This is a pain because it must be rewritten
> everytime we move to a new compile (or even a new version of the same).
>  Is there a way to do this in Standard Ada?  Our mission time is the
> number of seconds since an arbitrarily choosen epoch (1/1/1998) GMT.
> We originally used Time_Of, but had problems because Time_Of was using
> local time and did DST adjustments which were undesirable.

 function Time_Of
     (Year    : Year_Number;
      Month   : Month_Number;
      Day     : Day_Number;
      Seconds : Day_Duration := 0.0)
      return    Time;

I don't see how Time_Of would be "using" some daylight savings time
algorithm unless that is what you fed it.

If your operating system is set to make daylight savings time adjustments,
you should change that setting.

Re: Advice on Calendar.Time

[REH]

Larry Kilgallen wrote:
> In article <1131465873.702910.143400@g43g2000cwa.googlegroups.com>, "REH" <spamjunk@stny.rr.com> writes:
> > Ok, I have another problem:
> >
> > We have functions that convert between our mission time and
> > Ada.Calendar.Time.  The current implementation depends on the internal
> > representation of Time.  This is a pain because it must be rewritten
> > everytime we move to a new compile (or even a new version of the same).
> >  Is there a way to do this in Standard Ada?  Our mission time is the
> > number of seconds since an arbitrarily choosen epoch (1/1/1998) GMT.
> > We originally used Time_Of, but had problems because Time_Of was using
> > local time and did DST adjustments which were undesirable.
>
>  function Time_Of
>      (Year    : Year_Number;
>       Month   : Month_Number;
>       Day     : Day_Number;
>       Seconds : Day_Duration := 0.0)
>       return    Time;
>
> I don't see how Time_Of would be "using" some daylight savings time
> algorithm unless that is what you fed it.
>
> If your operating system is set to make daylight savings time adjustments,
> you should change that setting.

Well, it does.  Even the compilers' documentation say it does.

Re: Advice on Calendar.Time

[Wilhelm Spickermann]

Larry Kilgallen wrote:

> If your operating system is set to make daylight savings time
> adjustments, you should change that setting.

and additionally check for the handling of leap seconds. If your
operating system is using "posix"-time, it will _not_ count
positive leap seconds. There will be a positive leap second at
the end of this year:
(http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat)

Wilhelm

Re: Advice on Calendar.Time

[REH]

Wilhelm Spickermann wrote:
> Larry Kilgallen wrote:
>
> > If your operating system is set to make daylight savings time
> > adjustments, you should change that setting.
>
> and additionally check for the handling of leap seconds. If your
> operating system is using "posix"-time, it will _not_ count
> positive leap seconds. There will be a positive leap second at
> the end of this year:
> (http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat)
>
> Wilhelm

My main problem is we are evaluating several compilers (we are
upgrading, finally, to Ada 95).  I am trying to removed any
implemtation-specific things.  I was hoping to handle time without
needing to know if such things like posix are used or not, or whether
local time is used.

Re: Advice on Calendar.Time

[Martin Dowie]

REH wrote:
> Wilhelm Spickermann wrote:
> 
>>Larry Kilgallen wrote:
>>
>>
>>>If your operating system is set to make daylight savings time
>>>adjustments, you should change that setting.
>>
>>and additionally check for the handling of leap seconds. If your
>>operating system is using "posix"-time, it will _not_ count
>>positive leap seconds. There will be a positive leap second at
>>the end of this year:
>>(http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat)
>>
>>Wilhelm
> 
> 
> My main problem is we are evaluating several compilers (we are
> upgrading, finally, to Ada 95).  I am trying to removed any
> implemtation-specific things.  I was hoping to handle time without
> needing to know if such things like posix are used or not, or whether
> local time is used.

Not sure if it will 'fix' your problem but have you had a look at the 
extensions to Ada.Calendar in AI-351? There is an implementation at 
http://www.martin.dowie.btinternet.co.uk/

This can let you get from your timezone to UTC but I think the important 
thing to realize is that dealing with time turns out to be _very_ 
OS-dependent - even with a standardized API. :-(

Cheers

-- Martin

Re: Advice on Calendar.Time

[REH]

Martin Dowie wrote:

> This can let you get from your timezone to UTC but I think the important
> thing to realize is that dealing with time turns out to be _very_
> OS-dependent - even with a standardized API. :-(
>

When dealing with timer resolutions, frequencies, and precisions, sure,
I agree.  But I don't think there is anything that is, or should be,
OS-dependent with dates and time-of-day, or timezones, or GMT, or UTC,
or DST, or leap seconds, etc.  These concepts are well defined and do
not change from platform to platform.

Re: Advice on Calendar.Time

[Martin Dowie]

REH wrote:
> When dealing with timer resolutions, frequencies, and precisions, sure,
> I agree.  But I don't think there is anything that is, or should be,
> OS-dependent with dates and time-of-day, or timezones, or GMT, or UTC,
> or DST, or leap seconds, etc.  These concepts are well defined and do
> not change from platform to platform.

The concepts might not change but the implementations do - hence the 
implementation permissions.

Cheers

-- Martin

Re: Advice on Calendar.Time

[REH]

Martin Dowie wrote:
> REH wrote:
> > When dealing with timer resolutions, frequencies, and precisions, sure,
> > I agree.  But I don't think there is anything that is, or should be,
> > OS-dependent with dates and time-of-day, or timezones, or GMT, or UTC,
> > or DST, or leap seconds, etc.  These concepts are well defined and do
> > not change from platform to platform.
>
> The concepts might not change but the implementations do - hence the
> implementation permissions.
>
> Cheers
> 
> -- Martin

I'm sorry, but I don't understand you are saying.

Re: Advice on Calendar.Time

[Wilhelm Spickermann]

REH wrote:

> Butï¿œIï¿œdon'tï¿œthinkï¿œthereï¿œisï¿œanythingï¿œthatï¿œis,ï¿œorï¿œshouldï¿œbe,
> OS-dependent with dates and time-of-day, or timezones, or GMT,
> or UTC, or DST, or leap seconds, etc.ￜￜTheseￜconceptsￜareￜwell
> definedï¿œandï¿œdo not change from platform to platform.

I agree. But as the run time system normally depends on the OS
time services it depends on the configuration of these services. 

But even after having the operating system configured in a way
such that we have no DST and and no posix handling of leap
seconds, there will be at least one remaining problem:
Ada.Calendar is inherently POSIX: Day_Duration is too short for
a leap second and Time_Of called with a seconds value of
86_400.0 is forced by ARM 9.6-25 to return the same value as
Time_Of for the next day with seconds value of 0.0.

Wilhelm

Re: Advice on Calendar.Time

[REH]

Wilhelm Spickermann wrote:
> REH wrote:
>
> > But I don't think there is anything that is, or should be,
> > OS-dependent with dates and time-of-day, or timezones, or GMT,
> > or UTC, or DST, or leap seconds, etc.  These concepts are well
> > defined and do not change from platform to platform.
>
> I agree. But as the run time system normally depends on the OS
> time services it depends on the configuration of these services.
>
> But even after having the operating system configured in a way
> such that we have no DST and and no posix handling of leap
> seconds, there will be at least one remaining problem:
> Ada.Calendar is inherently POSIX: Day_Duration is too short for
> a leap second and Time_Of called with a seconds value of
> 86_400.0 is forced by ARM 9.6-25 to return the same value as
> Time_Of for the next day with seconds value of 0.0.
>
> Wilhelm

That's fine.  It's consistant.  The problem I am having is that there
is no consistant why to deal with knowing what time zone a particular
Ada implementation uses for Time, and how to force it to use GMT or
UTC.

Re: Advice on Calendar.Time

[Wilhelm Spickermann]

REH wrote:

>> But even after having the operating system configured in a way
>> such that we have no DST and and no posix handling of leap
>> seconds, there will be at least one remaining problem:
>> Ada.Calendar is inherently POSIX: Day_Duration is too short
>> for a leap second and Time_Of called with a seconds value of
>> 86_400.0 is forced by ARM 9.6-25 to return the same value as
>> Time_Of for the next day with seconds value of 0.0.
>>
>> Wilhelm
> 
> That's fine.

Really? There is no possibility to specify any point in time
during the positive leap second and there is no possibility to
have a meaningful time stamp there. And all time differences
between times before and times after the leap second will be
wrong. (The clock just stops running for a second, pretending
that this second doesn't exist -- very much like an analog wall
clock.) 

>ￜIt'sￜconsistant.ￜￜ

In itself -- yes. But it's not consistant with the clock in the
embedded system as that one counts (presumably) every second of
reality. But if you can live with that -- ok.

> ... and how to force it to use GMT or UTC.

In systems of the Unix family, it may suffice to set the TZ
environment variable for the image to be startet. In my
GNU/Linux I would start the program X with: "TZ=UTC X".

Wilhelm

Re: Advice on Calendar.Time

[Martin Dowie]

REH wrote:
> That's fine.  It's consistant.  The problem I am having is that there
> is no consistant why to deal with knowing what time zone a particular
> Ada implementation uses for Time, and how to force it to use GMT or
> UTC.

There is now:

Ada.Calendar.Time_Zones

see AI-351 @ http://www.martin.dowie.btinternet.co.uk/ (Win32 only 
implementation for that particular package)

Cheers

-- Martin

Re: Advice on Calendar.Time

[Jeffrey R. Carter]

REH wrote:
> 
> My main problem is we are evaluating several compilers (we are
> upgrading, finally, to Ada 95).  I am trying to removed any
> implemtation-specific things.  I was hoping to handle time without
> needing to know if such things like posix are used or not, or whether
> local time is used.

Does Ada.Real_Time (added in Ada 95) meet your needs? If we knew what you are 
trying to achieve, rather than what you're doing to try to achieve it, we might 
be able to be more helpful.

Just in time for Ada 0X :)

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21

Re: Advice on Calendar.Time

[Keith Thompson]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> In article <1131465873.702910.143400@g43g2000cwa.googlegroups.com>,
> "REH" <spamjunk@stny.rr.com> writes:
>> Ok, I have another problem:
>> 
>> We have functions that convert between our mission time and
>> Ada.Calendar.Time.  The current implementation depends on the internal
>> representation of Time.  This is a pain because it must be rewritten
>> everytime we move to a new compile (or even a new version of the same).
>>  Is there a way to do this in Standard Ada?  Our mission time is the
>> number of seconds since an arbitrarily choosen epoch (1/1/1998) GMT.
>> We originally used Time_Of, but had problems because Time_Of was using
>> local time and did DST adjustments which were undesirable.
>
>  function Time_Of
>      (Year    : Year_Number;
>       Month   : Month_Number;
>       Day     : Day_Number;
>       Seconds : Day_Duration := 0.0)
>       return    Time;
>
> I don't see how Time_Of would be "using" some daylight savings time
> algorithm unless that is what you fed it.

The time base associated with type Ada.Calendar.Time is implementation
defined; it's typically local time (however that's defined by the
system).  A note in the AARM even mentions the "missing hour" that
occurs when DST starts in the spring.

It's unfortunate, IMHO, that the standard doesn't explicitly support
both local time and UTC.

> If your operating system is set to make daylight savings time adjustments,
> you should change that setting.

That might be acceptable for an embedded system.  If it's a
user-oriented OS (like, say, Unix or Windows), making the system clock
incorrect by an hour for half of each year would be a very bad idea.

On some systems, time zone information has a default system-wide
value, but can be changed for individual processes.  Setting the $TZ
environment variable to "UTC" certainly isn't portable, but it might
be good enough for the OP's purposes.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: Advice on Calendar.Time

[Jacob Sparre Andersen]

Keith Thompson wrote:

> That might be acceptable for an embedded system.  If it's a
> user-oriented OS (like, say, Unix or Windows), making the system
> clock incorrect by an hour for half of each year would be a very bad
> idea.

Unix systems (at least those I have used) do actually by default run
the system clock on UTC without fiddling around with the hours twice a
year.  It is only the time shown to the users which is changed
(depending on where in the world they claim to be located).

> On some systems, time zone information has a default system-wide
> value, but can be changed for individual processes.  Setting the $TZ
> environment variable to "UTC" certainly isn't portable, but it might
> be good enough for the OP's purposes.

Fixing the Ada.Calendar system so you can request both UTC and "user
time" would be the right solution.  I hope this is done in Ada2005.

Jacob
-- 
�Great minds discuss ideas,
 Average minds discuss events,
 Small minds discuss people.�

Re: Advice on Calendar.Time

[Keith Thompson]

Jacob Sparre Andersen <sparre@nbi.dk> writes:
> Keith Thompson wrote:
>> That might be acceptable for an embedded system.  If it's a
>> user-oriented OS (like, say, Unix or Windows), making the system
>> clock incorrect by an hour for half of each year would be a very bad
>> idea.
>
> Unix systems (at least those I have used) do actually by default run
> the system clock on UTC without fiddling around with the hours twice a
> year.  It is only the time shown to the users which is changed
> (depending on where in the world they claim to be located).

Right, and the Unix approach is, IMHO, exactly the right one (ignoring
any leap-second issues).  The problem is that Ada.Calendar on
Unix-like systems typically uses local time, i.e., the system UTC
clock adjusted by any system-defined or user-defined time zone offset,
with no mechanism for going back to the underlying UTC time.

(I'm amplifying on what you wrote, not disagreeing with it.)

>> On some systems, time zone information has a default system-wide
>> value, but can be changed for individual processes.  Setting the $TZ
>> environment variable to "UTC" certainly isn't portable, but it might
>> be good enough for the OP's purposes.
>
> Fixing the Ada.Calendar system so you can request both UTC and "user
> time" would be the right solution.  I hope this is done in Ada2005.

I believe there are proposals to do just that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: Advice on Calendar.Time

[Stephen Leake]

"REH" <spamjunk@stny.rr.com> writes:

> We have functions that convert between our mission time and
> Ada.Calendar.Time.  

Why? As you have seen, this is problematic.

If you need some of the functions that operate on Calendar.Time,
perphaps you should reimplement them to work on your mission time.

I have a real-time system, and my own time type (64 bit fixed point).
I don't use Ada.Calendar.

-- 
-- Stephe

Re: Advice on Calendar.Time

[Dmitry A. Kazakov]

On 8 Nov 2005 08:04:33 -0800, REH wrote:

> We have functions that convert between our mission time and
> Ada.Calendar.Time.  The current implementation depends on the internal
> representation of Time.  This is a pain because it must be rewritten
> everytime we move to a new compile (or even a new version of the same).
>  Is there a way to do this in Standard Ada?  Our mission time is the
> number of seconds since an arbitrarily choosen epoch (1/1/1998) GMT.
> We originally used Time_Of, but had problems because Time_Of was using
> local time and did DST adjustments which were undesirable.

Unfortunately there is no portable way to deal with UTC in Ada.
Specifically for the problem of high resolution time stamping of data in a
distributed system there is nothing useful. Alas, but Ada 2005 will change
nothing here.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Advice on Calendar.Time

[brian.b.mcguinness]

So one approach would be to use Ada.Calendar.Time_Zones as Martin
suggested, e.g. get
the time of day from Clock, using Split to divide it into year, month,
day, and second, then get the time offset (in minutes) from
UTC_Time_Offset, and convert to GMT accordingly.  But the question
remains of how to deal with leap seconds.  (And why does
UTC_Time_Offset return a value in minutes rather than seconds, which
would make it more compatible with Split?)

Astronomers face a similar problem in converting conventional dates and
times to the Julian day number, the number of days since 00:00 GMT on
January 1, 4713 B.C.  They have software to keep track of leap seconds
and so on.  So you might find something useful in a package of
astronomical subroutines such as SOFA, which is at
http://www.iau-sofa.rl.ac.uk/
(this is in Fortran, not Ada, but it could probably be translated
without too much trouble or Fortran routines might be linked into an
Ada program).

Good luck.

--- Brian

Re: Advice on Calendar.Time

[brian.b.mcguinness]

brian.b.mcguinness@lmco.com wrote:

> Astronomers face a similar problem in converting conventional dates and
> times to the Julian day number, the number of days since 00:00 GMT on
> January 1, 4713 B.C.

Sorry, that should be 12:00 GMT on January 1, 4713 B.C.  They start at
noon.

--- Brian

Re: Advice on Calendar.Time

[Randy Brukardt]

<brian.b.mcguinness@lmco.com> wrote in message
news:1131565063.972303.313350@g44g2000cwa.googlegroups.com...
> So one approach would be to use Ada.Calendar.Time_Zones as Martin
> suggested, e.g. get
> the time of day from Clock, using Split to divide it into year, month,
> day, and second, then get the time offset (in minutes) from
> UTC_Time_Offset, and convert to GMT accordingly.  But the question
> remains of how to deal with leap seconds.  (And why does
> UTC_Time_Offset return a value in minutes rather than seconds, which
> would make it more compatible with Split?)

Because it's a separate strongly typed parameter to Split. You're supposed
to directly Split the time value into the parts, not try to adjust them
later. Nor are you supposed to add or subtract this value from a Time
object. (There were some members of the ARG who were very opposed to any
such semantics.)

                         Randy.