Ada.Calendar and NTP (and Unix Epoch)

Ada.Calendar and NTP (and Unix Epoch)

[erlo]

The following code raises an ADA.CALENDAR.TIME_ERROR exception:

with Calendar;
with Calendar.Conversions;
with Calendar.Arithmetic;
with Calendar.Formatting;
with Text_IO;
with Ada.Exceptions;

use Calendar;
use Text_IO;


procedure Main is
    AdaTid : Time;
begin
    AdaTid := Conversions.To_Ada_Time(tm_year  => 00,
                                      tm_mon   => 00,
                                      tm_day   => 01,
                                      tm_hour  => 0,
                                      tm_min   => 0,
                                      tm_sec   => 0,
                                      tm_isdst => 0); -- raises exception


    put_line(Formatting.Image(Date                  => AdaTid,
                              Include_Time_Fraction => False,
                              Time_Zone             => 0));

end Main;

This is because Ada.Calendar starts at 1-1-1901. But NTP starts at 
1-1-1900, so how can I work my way around this issue? I need to compare 
NTP time with Unix Epoch based time.

Erlo

Re: Ada.Calendar and NTP (and Unix Epoch)

[Adam Beneschan]

On Monday, July 23, 2012 2:42:32 PM UTC-7, erlo wrote:
> The following code raises an ADA.CALENDAR.TIME_ERROR exception:
> 
> with Calendar;
> with Calendar.Conversions;
> with Calendar.Arithmetic;
> with Calendar.Formatting;
> with Text_IO;
> with Ada.Exceptions;
> 
> use Calendar;
> use Text_IO;
> 
> 
> procedure Main is
>     AdaTid : Time;
> begin
>     AdaTid := Conversions.To_Ada_Time(tm_year  => 00,
>                                       tm_mon   => 00,
>                                       tm_day   => 01,
>                                       tm_hour  => 0,
>                                       tm_min   => 0,
>                                       tm_sec   => 0,
>                                       tm_isdst => 0); -- raises exception
> 
> 
>     put_line(Formatting.Image(Date                  => AdaTid,
>                               Include_Time_Fraction => False,
>                               Time_Zone             => 0));
> 
> end Main;
> 
> This is because Ada.Calendar starts at 1-1-1901. But NTP starts at 
> 1-1-1900, so how can I work my way around this issue?

My gut feeling is that if NTP gives you a time in the range 1-1-1900 to 12-31-1900, something is pretty wrong because computers didn't exist during that time period.  So I'm not really sure what the issue is.  I think you need to be more specific about what you're trying to do.  What kind of value is your program using for an "NTP time"--is it an integer, and if so, what does it represent (seconds since 1-1-1900, nanoseconds since 1-1-1900, or what)?  Are you trying to see if an NTP time is less than or greater than a value of Ada.Calendar.Time, or compute the difference in seconds (or something else) between an NTP time value and an Ada.Calendar.Time value, or what?  

                        -- Adam

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Tue, 24 Jul 2012 00:37:13 -0400, Dennis Lee Bieber wrote:

> On Mon, 23 Jul 2012 15:07:48 -0700 (PDT), Adam Beneschan
> <adam@irvine.com> declaimed the following in comp.lang.ada:
> 
> My gut feeling is that if NTP gives you a time in the range 1-1-1900 to
> 12-31-1900, something is pretty wrong because computers didn't exist
> during that time period.  So I'm not really sure what the issue is.  I
> think you need 
> 
> 	Nonetheless, it appears that a 128bit value of all 0s represents the
> epoch for Network Time Protocol...

Is NTP political time? If not, it does not make much sense to convert it
Ada.Calendar.Time anyway. Ada.Real_Time.Time looks more appropriate.

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[erlo.haugen]

> My gut feeling is that if NTP gives you a time in the range 1-1-1900 to 12-31-1900, something is pretty wrong because computers didn't exist during that time period.  So I'm not really sure what the issue is.  I think you need to be more specific about what you're trying to do.  What kind of value is your program using for an "NTP time"--is it an integer, and if so, what does it represent (seconds since 1-1-1900, nanoseconds since 1-1-1900, or what)?  Are you trying to see if an NTP time is less than or greater than a value of Ada.Calendar.Time, or compute the difference in seconds (or something else) between an NTP time value and an Ada.Calendar.Time value, or what?  
> 
>                         -- Adam
NTP epoch 1 started 1-1-1900 0:00, just like the Unix epoch started 1-1-1970 0:00. So when I get a time from an NTP-server, I get seconds from the start of the NTP epoch.

Erlo

Re: Ada.Calendar and NTP (and Unix Epoch)

[erlo.haugen]

> My gut feeling is that if NTP gives you a time in the range 1-1-1900 to 12-31-1900, something is pretty wrong because computers didn't exist during that time period.  So I'm not really sure what the issue is.  I think you need to be more specific about what you're trying to do.  What kind of value is your program using for an "NTP time"--is it an integer, and if so, what does it represent (seconds since 1-1-1900, nanoseconds since 1-1-1900, or what)?  Are you trying to see if an NTP time is less than or greater than a value of Ada.Calendar.Time, or compute the difference in seconds (or something else) between an NTP time value and an Ada.Calendar.Time value, or what?  
> 
>                         -- Adam
I want to compare two timestamps, a Unix timestamp and an NTP timestamp. Both are seconds since their respective epoch.

Erlo

Re: Ada.Calendar and NTP (and Unix Epoch)

[erlo.haugen]

Den tirsdag den 24. juli 2012 09.11.57 UTC+2 skrev Dmitry A. Kazakov:
> On Tue, 24 Jul 2012 00:37:13 -0400, Dennis Lee Bieber wrote:
> 
> > On Mon, 23 Jul 2012 15:07:48 -0700 (PDT), Adam Beneschan
> > <adam@irvine.com> declaimed the following in comp.lang.ada:
> > 
> > My gut feeling is that if NTP gives you a time in the range 1-1-1900 to
> > 12-31-1900, something is pretty wrong because computers didn't exist
> > during that time period.  So I'm not really sure what the issue is.  I
> > think you need 
> > 
> > 	Nonetheless, it appears that a 128bit value of all 0s represents the
> > epoch for Network Time Protocol...
> 
> Is NTP political time? If not, it does not make much sense to convert it
> Ada.Calendar.Time anyway. Ada.Real_Time.Time looks more appropriate.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Enlighten me please, what is meant by 'political time'?

Erlo

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Tue, 24 Jul 2012 00:50:15 -0700 (PDT), erlo.haugen@gmail.com wrote:

> Den tirsdag den 24. juli 2012 09.11.57 UTC+2 skrev Dmitry A. Kazakov:
>> On Tue, 24 Jul 2012 00:37:13 -0400, Dennis Lee Bieber wrote:
>> 
>> > On Mon, 23 Jul 2012 15:07:48 -0700 (PDT), Adam Beneschan
>> > <adam@irvine.com> declaimed the following in comp.lang.ada:
>> > 
>> > My gut feeling is that if NTP gives you a time in the range 1-1-1900 to
>> > 12-31-1900, something is pretty wrong because computers didn't exist
>> > during that time period.  So I'm not really sure what the issue is.  I
>> > think you need 
>> > 
>> > 	Nonetheless, it appears that a 128bit value of all 0s represents the
>> > epoch for Network Time Protocol...
>> 
>> Is NTP political time? If not, it does not make much sense to convert it
>> Ada.Calendar.Time anyway. Ada.Real_Time.Time looks more appropriate.
> 
> Enlighten me please, what is meant by 'political time'?

Political time is one regulated by politicians, localized, daylight saving
etc. Political time is unusable for the purpose of time stamping and clock
synchronization, but of course indispensable for the UI.

Ada.Calendar implicitly represents such a time. NTP, I only guess, because
we are using other mechanisms of time distribution and synchronization, is
not a political time. Is it UTC?

Which is why I second to Adam asking what are going to achieve.

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[erlo.haugen]

> Political time is one regulated by politicians, localized, daylight saving
> etc. Political time is unusable for the purpose of time stamping and clock
> synchronization, but of course indispensable for the UI.
> 
> Ada.Calendar implicitly represents such a time. NTP, I only guess, because
> we are using other mechanisms of time distribution and synchronization, is
> not a political time. Is it UTC?
> 
> Which is why I second to Adam asking what are going to achieve.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

I see. NTP is just the number of seconds (and fractions thereof) from 1-1-1900 0:00, adjusted with leap seconds - so it is not adjusted for timezones, daylight saving. It is not UTC, as UTC does not take leap seconds in account.

The purpose of this exercise is to compare two timestamps, one base on Unix epoch and one based on NTP epoch.

Regards
Erlo

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Tue, 24 Jul 2012 01:34:03 -0700 (PDT), erlo.haugen@gmail.com wrote:

>> Political time is one regulated by politicians, localized, daylight saving
>> etc. Political time is unusable for the purpose of time stamping and clock
>> synchronization, but of course indispensable for the UI.
>> 
>> Ada.Calendar implicitly represents such a time. NTP, I only guess, because
>> we are using other mechanisms of time distribution and synchronization, is
>> not a political time. Is it UTC?
>> 
>> Which is why I second to Adam asking what are going to achieve.
> 
> I see. NTP is just the number of seconds

Any time is just a number of seconds added to some epoch...

> The purpose of this exercise is to compare two timestamps, one base on
> Unix epoch and one based on NTP epoch.

Where is a problem then?

   E1 + T1 vs. E2 + T2

<=>

   T1 vs. (E2 - E1) + T2

Where E2 - E1 is the time offset between the epochs.

This presumes that they represent *same* time though maybe using different
epochs. You might need to read the UNIX and NTP documentation to learn what
exactly times they do represent. That would give you E2 - E1. To put it
simple: same time = synchronized clocks.

Note that if any of two times is political, E2 - E1 does not exist as it
becomes a function of time. This where all starts really complicated and is
the reason why one should never ever mess up with the political time for
the purpose of time stamping. And this is just a relatively simple case
when clocks are synchronized but one of them is periodically skewed.

When clocks are not synchronized, time stamps are fundamentally
incomparable without the history of synchronization, which, well, means
that they were rather synchronized. (:-))

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[Simon Wright]

erlo <erlo@none> writes:

> This is because Ada.Calendar starts at 1-1-1901. But NTP starts at
> 1-1-1900, so how can I work my way around this issue? I need to
> compare NTP time with Unix Epoch based time.

I did it by (effectively) working backward from the next NTP epoch (I
treated NTP time as signed, so that the current NTP time is a negative
number), which according to the code I have here[1] is
2036-02-07:06:28:16 (this should fit with Unix time, but I just used
Ada).

[1]
http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/file/a6fd7b0dfeba/SNTP.impl/sntp_support.ads
http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/file/a6fd7b0dfeba/SNTP.impl/sntp_support.adb

Re: Ada.Calendar and NTP (and Unix Epoch)

[Nasser M. Abbasi]

On 7/24/2012 6:34 AM, Simon Wright wrote:
> erlo <erlo@none> writes:
>

>
> [1]
> http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/file/a6fd7b0dfeba/SNTP.impl/sntp_support.ads
> http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/file/a6fd7b0dfeba/SNTP.impl/sntp_support.adb
>

hi Simon,


just a side note. If you have control of the HTML formating itself, or know
who does, then the above pages are really hard on the eyes to look at due to
the background of the HTML page.

It has those annoying white and gray stripes. This makes it hard
to read text as it leaves double images after effect in the eyes afterwords.

May be just basic white background will be better.

--Nasser

Re: Ada.Calendar and NTP (and Unix Epoch)

[erlo.haugen]

> Where is a problem then?
> 
>    E1 + T1 vs. E2 + T2
> 
> <=>
> 
>    T1 vs. (E2 - E1) + T2
> 
> Where E2 - E1 is the time offset between the epochs.

That's true, the issue here is that I was fooled by Ada.Calendar.Conversion spec
into thinking that I can use To_Ada_Time to convert the NTP epoch base (1-1-1900 0:00) to a variable of type Time. This would make it easy to calculate
the offset between the two epochs:
epoch_diff := To_Ada_Time(70, 0, 1, 0, 0 ,0 0) - To_Ada_Time(00, 0, 1, 0, 0 ,0 0)

Snip from Ada.Calendar.Conversion spec:

  function To_Ada_Time
     (tm_year  : Interfaces.C.int;
      tm_mon   : Interfaces.C.int;
      tm_day   : Interfaces.C.int;
      tm_hour  : Interfaces.C.int;
      tm_min   : Interfaces.C.int;
      tm_sec   : Interfaces.C.int;
      tm_isdst : Interfaces.C.int) return Time;
   --  Convert a time value expressed in Unix-like fields of struct tm into
   --  a Time value relative to the Ada Epoch. The ranges of the formals are
   --  as follows:

   --     tm_year   --  years since 1900 *this one fooled me*
   --     tm_mon    --  months since January [0 .. 11]

I had the idea that zero would be a legal value for tm_year...

> 
> This presumes that they represent *same* time though maybe using different
> epochs. You might need to read the UNIX and NTP documentation to learn what
> exactly times they do represent. That would give you E2 - E1. To put it
> simple: same time = synchronized clocks.
> 

This is the exact case.

> Note that if any of two times is political, E2 - E1 does not exist as it
> becomes a function of time. This where all starts really complicated and is
> the reason why one should never ever mess up with the political time for
> the purpose of time stamping. And this is just a relatively simple case
> when clocks are synchronized but one of them is periodically skewed.
> 
> When clocks are not synchronized, time stamps are fundamentally
> incomparable without the history of synchronization, which, well, means
> that they were rather synchronized. (:-))
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Erlo

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Tue, 24 Jul 2012 05:27:30 -0700 (PDT), erlo.haugen@gmail.com wrote:

>> Where is a problem then?
>> 
>>    E1 + T1 vs. E2 + T2
>> 
>> <=>
>> 
>>    T1 vs. (E2 - E1) + T2
>> 
>> Where E2 - E1 is the time offset between the epochs.
> 
> That's true, the issue here is that I was fooled by Ada.Calendar.Conversion spec

Is it a standard Ada package?

> into thinking that I can use To_Ada_Time to convert the NTP epoch base
> (1-1-1900 0:00) to a variable of type Time.

Take some other base, e.g. 01.01.2010 00:00 [UTC, GMT, CET ...], if you
have an NTP reading of it. E.g. if NTP uses some astronomical year or other
method to calculate difference between two times.

You should not use Ada.Calendar without knowing exactly what time it
represents on the given machine.

>> This presumes that they represent *same* time though maybe using different
>> epochs. You might need to read the UNIX and NTP documentation to learn what
>> exactly times they do represent. That would give you E2 - E1. To put it
>> simple: same time = synchronized clocks.
> 
> This is the exact case.

Which I doubt, but anyway.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Calendar and NTP (and Unix Epoch)

[erlo]

On 07/24/2012 03:02 PM, Dmitry A. Kazakov wrote:
>
> Is it a standard Ada package?
I guess it's a gnat-specific package - I can't find it in the RM.
>
>> into thinking that I can use To_Ada_Time to convert the NTP epoch base
>> (1-1-1900 0:00) to a variable of type Time.
>
> Take some other base, e.g. 01.01.2010 00:00 [UTC, GMT, CET ...], if you
> have an NTP reading of it. E.g. if NTP uses some astronomical year or other
> method to calculate difference between two times.
>
I will try this approach.
> You should not use Ada.Calendar without knowing exactly what time it
> represents on the given machine.
>
>>> This presumes that they represent *same* time though maybe using different
>>> epochs. You might need to read the UNIX and NTP documentation to learn what
>>> exactly times they do represent. That would give you E2 - E1. To put it
>>> simple: same time = synchronized clocks.
>>
>> This is the exact case.
>
> Which I doubt, but anyway.
>
>
--
Regards
Erlo

Re: Ada.Calendar and NTP (and Unix Epoch)

[Simon Wright]

"Nasser M. Abbasi" <nma@12000.org> writes:

> On 7/24/2012 6:34 AM, Simon Wright wrote:
>> erlo <erlo@none> writes:
>>
>
>>
>> [1]
>> http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/file/a6fd7b0dfeba/SNTP.impl/sntp_support.ads
>> http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/file/a6fd7b0dfeba/SNTP.impl/sntp_support.adb
>>
>
> hi Simon,
>
>
> just a side note. If you have control of the HTML formating itself, or
> know who does, then the above pages are really hard on the eyes to
> look at due to the background of the HTML page.
>
> It has those annoying white and gray stripes. This makes it hard to
> read text as it leaves double images after effect in the eyes
> afterwords.
>
> May be just basic white background will be better.

Sorry to hear that. They look quite attractive to me!

They are from a standard Mercurial stylesheet, which says (inter alia)

   .parity0 { background-color: #f0f0f0; }
   .parity1 { background-color: white; }

and we'd have to change the first line to

   .parity0 { background-color: white; }

(or maybe a less deep grey).
(or even a pale green, for those of us who remember lineprinters!)

But I don't know how to do that, especially on Sourceforge (they haven't
been receptive to similar style suggestions in the past).

Re: Ada.Calendar and NTP (and Unix Epoch)

[Adam Beneschan]

On Tuesday, July 24, 2012 12:24:17 AM UTC-7, erlo....@gmail.com wrote:

> NTP epoch 1 started 1-1-1900 0:00, just like the Unix epoch started 1-1-1970
> 0:00. So when I get a time from an NTP-server, I get seconds from the start of 
> the NTP epoch.

All right, then.  First of all, I don't know what Ada.Calendar.Conversions is.  It's not defined by the language, but rather by one particular implementor.  IMHO you should prefer to use the language-defined packages if at all feasible.  It will be more portable, plus a lot of work goes into making sure things in the Standard have precise definitions.  

If you have an integer value N representing the number of seconds since 1/1/1900, I think you want to convert this to an Ada.Calendar.Time that represents the same point in time, so that you can then compare it easily to another value of Ada.Calendar.Time.  If Ada had a Time that represented 1/1/1900, you could just take that Time and add N seconds to it.  But, as you found out, it didn't, so the first step is to convert N to a value N2 representing the number of seconds since 1/1/1901.  You can do this by setting N2 := N - constant (you'd better be able to figure out what the constant is!).  As I implied before, if N2 is negative then some very weird stuff is going on, so don't worry about that possibility.

Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901. 
Or, better, if the NTP time is always UTC, then you should probably use Ada.Calendar.Formatting.Time_Of to create a time that represents midnight of 1/1/1901 in UTC time; I think you do this by passing Time_Zone => Ada.Calendar.Time_Zones.UTC_Time_Offset.  (Somebody please correct me if I'm supposed to negate the value.)

Now, you *may* be able to create a Time T representing your NTP time just by setting

   T := T_Base + Duration(N2);

This will work on some implementations.  On other implementations, though, Duration isn't guaranteed to have a range that covers 112 years or more (the language only requires that it covers one day).  You can get around this by breaking N2 into "days" and "seconds":

   N2_Days := N2 / 86_400;
   N2_Seconds := N2 mod 86_400;
   T := T_Base + Day_Count (N2_Days) + Duration (N2_Seconds);

The Day_Count type is defined in Ada.Calendar.Arithmetic.

Now T will be a Time value that represents the point in time that occurred N seconds after midnight on 1/1/1900 (UTC), and you can compare this to any other Time value.

                          -- Adam

Re: Ada.Calendar and NTP (and Unix Epoch)

[Adam Beneschan]

On Tuesday, July 24, 2012 5:27:30 AM UTC-7, erlo....@gmail.com wrote:
> > Where is a problem then?
> > 
> >    E1 + T1 vs. E2 + T2
> > 
> > <=>
> > 
> >    T1 vs. (E2 - E1) + T2
> > 
> > Where E2 - E1 is the time offset between the epochs.
> 
> That's true, the issue here is that I was fooled by Ada.Calendar.Conversion spec
> into thinking that I can use To_Ada_Time to convert the NTP epoch base (1-1-1900 0:00) to a variable of type Time. This would make it easy to calculate
> the offset between the two epochs:
> epoch_diff := To_Ada_Time(70, 0, 1, 0, 0 ,0 0) - To_Ada_Time(00, 0, 1, 0, 0 ,0 0)

If all you're trying to do is figure out the number of seconds between 1/1/1970 and 1/1/1900 by using an Ada Time type, you can do this easily by figuring out the number of seconds between 1/1/1970 and 1/1/1901, and adding a constant.

                           -- Adam

Re: Ada.Calendar and NTP (and Unix Epoch)

[Georg Bauhaus]

On 24.07.12 17:08, Simon Wright wrote:
> "Nasser M. Abbasi" <nma@12000.org> writes:
> 
>> On 7/24/2012 6:34 AM, Simon Wright wrote:
>>> erlo <erlo@none> writes:
>>>
>>
>>>
>>> [1]
>>> http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/file/a6fd7b0dfeba/SNTP.impl/sntp_support.ads
>>> http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/file/a6fd7b0dfeba/SNTP.impl/sntp_support.adb
>>>
>>
>> hi Simon,
>>
>>
>> just a side note. If you have control of the HTML formating itself, or
>> know who does, then the above pages are really hard on the eyes to
>> look at due to the background of the HTML page.

> 
> They are from a standard Mercurial stylesheet, which says (inter alia)
> 
>    .parity0 { background-color: #f0f0f0; }
>    .parity1 { background-color: white; }
> 
> and we'd have to change the first line to
> 
>    .parity0 { background-color: white; }
> 
> (or maybe a less deep grey).
> (or even a pale green, for those of us who remember lineprinters!)
> 
> But I don't know how to do that, especially on Sourceforge (they haven't
> been receptive to similar style suggestions in the past).

In the end, the world frame operators will succeed in convincing
computer users that they always need to ask the operator do
anything with their computers. It is very well possible to adjust
CSS settings to personal preferences using what is called
a user style sheet.

It's your personal computer. Yours. Sapere aude!

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Tue, 24 Jul 2012 09:26:46 -0700 (PDT), Adam Beneschan wrote:

> Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901. 
> Or, better, if the NTP time is always UTC, then you should probably use
> Ada.Calendar.Formatting.Time_Of to create a time that represents midnight
> of 1/1/1901 in UTC time; I think you do this by passing Time_Zone =>
> Ada.Calendar.Time_Zones.UTC_Time_Offset.  (Somebody please correct me if
> I'm supposed to negate the value.)

There is no simple way of converting Ada.Calendar.Time to UTC. At least
there was none in Ada 2005. I think Randy Brukardt wanted to fix that, or
sort of.

The problem is that UTC_Time_Offset has time argument. It is not constant.
UTC_Time_Offset jumps forth and back together with the political time.

Furthermore, operations like UTC_Time_Offset, Time_Of, Split for some
distant time in the past, e.g. 1901 are most likely wrong, because OS/Ada's
RTL cannot keep track of all political changes of all time zones in order
to be able to evaluate the number of seconds from present time to 1901 in
the time zone. It is *not* the number of years multiplied by the year's
duration. (IANA Time Zone Database or alike is required for that)

Calculating future times is absolutely impossible because that depends on
future decisions of the corresponding governmental bodies having the
authority over the time zone, from daylight saving time to changing the
whole zone.

This is why it is better not to touch Ada.Calendar.Time.

Ada.Real_Time, Duration, Time_Span, some numeric type would be much better
candidates.

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[Adam Beneschan]

On Tuesday, July 24, 2012 11:28:27 AM UTC-7, Dmitry A. Kazakov wrote:
> On Tue, 24 Jul 2012 09:26:46 -0700 (PDT), Adam Beneschan wrote:
> 
> > Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901. 
> > Or, better, if the NTP time is always UTC, then you should probably use
> > Ada.Calendar.Formatting.Time_Of to create a time that represents midnight
> > of 1/1/1901 in UTC time; I think you do this by passing Time_Zone =>
> > Ada.Calendar.Time_Zones.UTC_Time_Offset.  (Somebody please correct me if
> > I'm supposed to negate the value.)
> 
> There is no simple way of converting Ada.Calendar.Time to UTC. At least
> there was none in Ada 2005. I think Randy Brukardt wanted to fix that, or
> sort of.

The problem here, I think, is that the concept of "converting Ada.Calendar.Time to UTC" is a broad, general one, and probably somewhat vague.  I'm not trying to explain how to work with UTC time in general; I'm trying to solve a specific problem.

The specific problem (as I understood it) was this:  You have an integer value that represents a specific *point* *in* *time* T1 by specifying the number of seconds that have elapsed since midnight on New Years Day in Greenwich.  You have another value that was returned by Ada.Calendar.Clock at some other point in time T2.  My contention is that you can create an Ada.Calendar.Time value to represent T1 by using Ada.Calendar.Formatting.Time_Of with a suitable Time_Offset, and using the "+" functions defined in Ada.Calendar and Ada.Calendar.Formatting, that produces an Ada.Calendar.Time value representing T1 that can correctly be compared with T2 (and subtracted to produce a Duration).

Do you believe my contention is incorrect?  If so, please demonstrate.

It's true, as you say, that UTC_Time_Offset's result isn't constant, and changes when the time zone goes in and out of Daylight Savings Time.  The point is, I was trying to use it in a way that would cancel out the effect of that, producing a result in which the "offsets" factored into the two Ada.Calendar.Time values being compared are the same, which means that you can compare or subtract them correctly, regardless of whether the offsets would be different if you ran the program six months from now.  I may have done it wrong, but I don't believe it is impossible.  If it is, please show why.

There are certainly a lot of things that are difficult to get right with Ada.Calendar for some of the reasons you state.  I don't think any of those are relevant to solving *this* particular problem.  Furthermore, I don't see how Ada.Real_Time is a solution; that package's purpose is, I think, to provide a better way to measure time *intervals* with a higher resolution, but it doesn't do all that well with absolute time (the RM says that Real_Time is considered relative to an undefined "epoch" that could be the last system boot time).  So I don't see how it could be involved in a solution to this particular problem.

                            -- Adam

Re: Ada.Calendar and NTP (and Unix Epoch)

[John B. Matthews]

In article <jum2mm$4vi$1@speranza.aioe.org>,
 "Nasser M. Abbasi" <nma@12000.org> wrote:

> May be just basic white background will be better.

Choosing the _raw_ link may be an alternative:

<http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/raw-file/a6f
d7b0dfeba/SNTP.impl/sntp_support.ads>

<http://coldframe.hg.sourceforge.net/hgweb/coldframe/adasntp/raw-file/a6f
d7b0dfeba/SNTP.impl/sntp_support.adb>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Ada.Calendar and NTP (and Unix Epoch)

[Simon Wright]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> In the end, the world frame operators will succeed in convincing
> computer users that they always need to ask the operator do anything
> with their computers. It is very well possible to adjust CSS settings
> to personal preferences using what is called a user style sheet.

I couldn't see a way to do this with Safari. I followed the recipe I
found on the Web for Firefox: no effect.

On Chrome I found Stylish which does the trick; I had to include both
.parity0 and .parity1 settings to eliminate all trace.

However, I will now disable it, since I quite like the effect complained
of!

Re: Ada.Calendar and NTP (and Unix Epoch)

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Tue,  
24 Jul 2012 22:28:27 +0400:

> Furthermore, operations like UTC_Time_Offset, Time_Of, Split for some
> distant time in the past, e.g. 1901 are most likely wrong, because  
> OS/Ada's
> RTL cannot keep track of all political changes of all time zones in order
> to be able to evaluate the number of seconds from present time to 1901 in
> the time zone. It is *not* the number of years multiplied by the year's
> duration. (IANA Time Zone Database or alike is required for that)
>
> Calculating future times is absolutely impossible because that depends on
> future decisions of the corresponding governmental bodies having the
> authority over the time zone, from daylight saving time to changing the
> whole zone.

I took a look at  
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0119-1.txt

And I can say that there is a mis .... "misviewving" of the Time, UTC time  
and Zoned Time (political)

While typical application takes time from some sort of monotonic time  
source (e.g. clock), which is supposed to be one and authoritative for  
such application, it is in the same moment this application also deals  
with time representation, and a "political" time (zoned) is one of such  
representations.

Probably and personally, I don't prefer to convert between representations  
and catch one or two hour diffs, instead I prefer to do calculations  
better done with monotonic time, and then convert result to the required  
representation.

Converting from some representation into authoritative monotonic time is  
"mission impossibe", since important data may be lost, because this  
important data belongs entirely to the representation, and can not be  
expressed in monotonic authoritative source.

Things like "ada.calendar is a fake" are just based on "speculative  
cone-moving" between "time real value" and "time representation".

>
> This is why it is better not to touch Ada.Calendar.Time.
>
> Ada.Real_Time, Duration, Time_Span, some numeric type would be much  
> better
> candidates.
>


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Tue, 24 Jul 2012 12:07:52 -0700 (PDT), Adam Beneschan wrote:

> On Tuesday, July 24, 2012 11:28:27 AM UTC-7, Dmitry A. Kazakov wrote:
>> On Tue, 24 Jul 2012 09:26:46 -0700 (PDT), Adam Beneschan wrote:
>> 
>> > Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901. 
>> > Or, better, if the NTP time is always UTC, then you should probably use
>> > Ada.Calendar.Formatting.Time_Of to create a time that represents midnight
>> > of 1/1/1901 in UTC time; I think you do this by passing Time_Zone =>
>> > Ada.Calendar.Time_Zones.UTC_Time_Offset.  (Somebody please correct me if
>> > I'm supposed to negate the value.)
>> 
>> There is no simple way of converting Ada.Calendar.Time to UTC. At least
>> there was none in Ada 2005. I think Randy Brukardt wanted to fix that, or
>> sort of.
> 
> The problem here, I think, is that the concept of "converting
> Ada.Calendar.Time to UTC" is a broad, general one, and probably somewhat
> vague.  I'm not trying to explain how to work with UTC time in general;
> I'm trying to solve a specific problem.
> 
> The specific problem (as I understood it) was this:  You have an integer
> value that represents a specific *point* *in* *time* T1 by specifying the
> number of seconds that have elapsed since midnight on New Years Day in
> Greenwich.

T1 [GMT]

> You have another value that was returned by Ada.Calendar.Clock at some
> other point in time T2.

T2 [nobody knows what]

>  My contention is that you can create an Ada.Calendar.Time value to
> represent T1 by using Ada.Calendar.Formatting.Time_Of with a suitable
> Time_Offset,

The problem is the Time_Offset, where do you get it? You need
GMT_Time_Offset, which firstly is not defined, and secondly if it were
there, it would be no more constant than the UTC_Time_Offset is.

Once you get T1 and T2 to the same time basis of more or less monotonic
time, e.g. GMT, UTC, whatever, but *not* a political time, there will be no
further problems.

> Furthermore, I don't see how Ada.Real_Time is a solution; that package's
> purpose is, I think, to provide a better way to measure time *intervals*
> with a higher resolution, but it doesn't do all that well with absolute
> time (the RM says that Real_Time is considered relative to an undefined
> "epoch" that could be the last system boot time).  So I don't see how it
> could be involved in a solution to this particular problem.

Ada.Real_Time.Time is not a full solution. It only provides sane time
arithmetic, e.g. "+", "-". A numeric type could do this as well.

Ada.Calendar.Time cannot give even that little. You could not define
arithmetical operations on it in any reasonable way. This is of course
because of time skews, which make some values non-existent and some values
repeating. I presume that any Ada implementation of it is broken in this or
other way, which is irrelevant here, because there is no way to have
arithmetic on something that is not additive anyway. I posted a couple
examples for CET on the topic to Ada Comments some time ago.

So the rule is: do not do any computations with Ada.Calendar.Time. Ada RM
simply does not define the outcome.

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Tue, 24 Jul 2012 23:43:49 +0400, Vasiliy Molostov wrote:

> Probably and personally, I don't prefer to convert between representations  
> and catch one or two hour diffs, instead I prefer to do calculations  
> better done with monotonic time, and then convert result to the required  
> representation.

This is the only right way to do it.
 
> Converting from some representation into authoritative monotonic time is  
> "mission impossibe", since important data may be lost, because this  
> important data belongs entirely to the representation, and can not be  
> expressed in monotonic authoritative source.

Possible, but under two conditions:

1. the corresponding time sources are synchronized;

2. the representation is sane (anything but political time).

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[Simon Wright]

erlo.haugen@gmail.com writes:

>> My gut feeling is that if NTP gives you a time in the range 1-1-1900
>> to 12-31-1900, something is pretty wrong because computers
>> didn't exist during that time period.  So I'm not really
>> sure what the issue is.  I think you need to be more specific about
>> what you're trying to do.  What kind of value is your program
>> using for an "NTP time"--is it an integer, and if so, what
>> does it represent (seconds since 1-1-1900, nanoseconds since
>> 1-1-1900, or what)?  Are you trying to see if an NTP time is less
>> than or greater than a value of Ada.Calendar.Time, or compute the
>> difference in seconds (or something else) between an NTP time value
>> and an Ada.Calendar.Time value, or what?
>> 
>>                         -- Adam
> NTP epoch 1 started 1-1-1900 0:00, just like the Unix epoch started
> 1-1-1970 0:00. So when I get a time from an NTP-server, I get seconds
> from the start of the NTP epoch.

Yes; but if you regard the 64-bit value as a *signed* value then the
current NTP value is about -24 years. The next NTP epoch is in 2036,
which is easily representable in Ada.Calendar.Time. So, *add* -24 to
2036 and, presto, 2012! In UTC.

Of course, if you are worried about leap seconds, you are in for a world
of pain either way.

From Wikipedia[1],

   NTP delivers UTC time. UTC is subject to scheduled leap seconds to
   synchronize the timescale to the rotation of the earth. When a leap
   second is added, NTP is suspended for 1 second. Because NTP has no
   mechanism for remembering the history of leap seconds, leap seconds
   cause the entire NTP timescale to shift by 1 second.

[1] http://en.wikipedia.org/wiki/Network_Time_Protocol#Leap_seconds

Re: Ada.Calendar and NTP (and Unix Epoch)

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Wed,  
25 Jul 2012 00:29:00 +0400:

> On Tue, 24 Jul 2012 23:43:49 +0400, Vasiliy Molostov wrote:
>
>> Probably and personally, I don't prefer to convert between  
>> representations
>> and catch one or two hour diffs, instead I prefer to do calculations
>> better done with monotonic time, and then convert result to the required
>> representation.
>
> This is the only right way to do it.
>
>> Converting from some representation into authoritative monotonic time is
>> "mission impossibe", since important data may be lost, because this
>> important data belongs entirely to the representation, and can not be
>> expressed in monotonic authoritative source.
>
> Possible, but under two conditions:
>
> 1. the corresponding time sources are synchronized;

If you can synchronize representations, you are a god of time  
representations. Be aware of Mars orbiter time representation and its  
political times.
Also take into account that a matter of some incorrectly raised question  
may issue very ample answers, involving presidential elections also.

In a nut shell, a transformational function for converting *time  
representation* should take into account those parameters, that you have  
not in your (or your opponent) application, so you can tell only relative  
*time representation*, relative to your environment, in which your app (or  
your opponent) running. It is very funny to see people converting these  
relative things on the fly (without parametrized transformation, unlinked  
to the common and absolute source), and concluding that they don't match  
something speculatively implied, indeed. Even if these are syncronized.

>
> 2. the representation is sane (anything but political time).
>

It is sane by legislative rules that are out of Ada standard control, you  
know. It is very obvious question, and I see this as an intentional  
mistake.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada.Calendar and NTP (and Unix Epoch)

[Georg Bauhaus]

On 24.07.12 21:25, Simon Wright wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>
>> In the end, the world frame operators will succeed in convincing
>> computer users that they always need to ask the operator do anything
>> with their computers. It is very well possible to adjust CSS settings
>> to personal preferences using what is called a user style sheet.
>
> I couldn't see a way to do this with Safari. I followed the recipe I
> found on the Web for Firefox: no effect.

The following four lines in a user style sheet would be radical.
Tested with Safari (after restart):

* {
      background-color: white ! important;
      color: black ! important;
}

Re: Ada.Calendar and NTP (and Unix Epoch)

[sla29970]

On Monday, July 23, 2012 2:42:32 PM UTC-7, erlo wrote:
> This is because Ada.Calendar starts at 1-1-1901. But NTP starts at 
> 1-1-1900, so how can I work my way around this issue? I need to compare 
> NTP time with Unix Epoch based time.

What time scale is being used?  Is that time scale counting mean solar seconds or atomic seconds?  Of course UTC and atomic time did not exist at those epochs, but unless the situation defines the time scale a problem exists even if the year in question is 1972.  See
http://www.ucolick.org/~sla/leapsecs/epochtime.html

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Wed, 25 Jul 2012 01:22:55 +0400, Vasiliy Molostov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Wed,  
> 25 Jul 2012 00:29:00 +0400:
> 
>> On Tue, 24 Jul 2012 23:43:49 +0400, Vasiliy Molostov wrote:
>>
>>> Converting from some representation into authoritative monotonic time is
>>> "mission impossibe", since important data may be lost, because this
>>> important data belongs entirely to the representation, and can not be
>>> expressed in monotonic authoritative source.
>>
>> Possible, but under two conditions:
>>
>> 1. the corresponding time sources are synchronized;
> 
> If you can synchronize representations, you are a god of time  
> representations.

Synchronization does not necessarily means that you control the clocks. 

However it is true that the effect of clock synchronization is by
definition local. In particular it implies that more distant time stamps
are less sense any conversion would make. In short, some real-time clock
readings can be converted if synchronized. Anything else is most likely
garbage.

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Tue, 24 Jul 2012 19:23:52 -0700 (PDT), sla29970@gmail.com wrote:

> On Monday, July 23, 2012 2:42:32 PM UTC-7, erlo wrote:
>> This is because Ada.Calendar starts at 1-1-1901. But NTP starts at 
>> 1-1-1900, so how can I work my way around this issue? I need to compare 
>> NTP time with Unix Epoch based time.
> 
> What time scale is being used?  Is that time scale counting mean solar
> seconds or atomic seconds?  Of course UTC and atomic time did not exist at
> those epochs, but unless the situation defines the time scale a problem
> exists even if the year in question is 1972.  See
> http://www.ucolick.org/~sla/leapsecs/epochtime.html

A great link. Thanks!

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Wed,  
25 Jul 2012 10:32:05 +0400:

>>
>> If you can synchronize representations, you are a god of time
>> representations.
>
> Synchronization does not necessarily means that you control the clocks.

Do you see the terminology diff: "time represented"  and "time valued"?
Why you insist on false obvious mistake you follow due to this difference?

As for ai05-0119-1, do you understand that calculating linear algebra
equation with n variables can give you a complex number in the answer?

> However it is true that the effect of clock synchronization is by
> definition local. In particular it implies that more distant time stamps
> are less sense any conversion would make. In short, some real-time clock
> readings can be converted if synchronized. Anything else is most likely
> garbage.

wow.
rook gambits are tied (С).

btw, the effect of clock syncronization is at least country wide. Airbus  
rulez! :)

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Wed, 25 Jul 2012 11:04:05 +0400, Vasiliy Molostov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Wed,  
> 25 Jul 2012 10:32:05 +0400:
> 
>>> If you can synchronize representations, you are a god of time
>>> representations.
>>
>> Synchronization does not necessarily means that you control the clocks.
> 
> Do you see the terminology diff: "time represented"  and "time valued"?
> Why you insist on false obvious mistake you follow due to this difference?

There is certainly no such thing as "time value." What is the point?
 
> As for ai05-0119-1, do you understand that calculating linear algebra
> equation with n variables can give you a complex number in the answer?

No, it does not, provided you meant real coefficients. A solution of such a
set of linear equations is real when exists. When does not exist. It also
does not in the field of complex numbers.

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Wed,  
25 Jul 2012 11:33:17 +0400:

> On Wed, 25 Jul 2012 11:04:05 +0400, Vasiliy Molostov wrote:
>
>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме  
>> Wed,
>> 25 Jul 2012 10:32:05 +0400:
>>
>>>> If you can synchronize representations, you are a god of time
>>>> representations.
>>>
>>> Synchronization does not necessarily means that you control the clocks.
>>
>> Do you see the terminology diff: "time represented"  and "time valued"?
>> Why you insist on false obvious mistake you follow due to this  
>> difference?
>
> There is certainly no such thing as "time value." What is the point?

It is the source of time representation.

>> As for ai05-0119-1, do you understand that calculating linear algebra
>> equation with n variables can give you a complex number in the answer?
>
> No, it does not, provided you meant real coefficients. A solution of  
> such a
> set of linear equations is real when exists. When does not exist. It also
> does not in the field of complex numbers.

I meant complex, that giving simple arithmetic calculus you have got  
complex answer. I can only guess, that this came from speculative imply of  
some variables that are not reflected in the expression.


>


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Wed, 25 Jul 2012 12:05:51 +0400, Vasiliy Molostov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Wed,  
> 25 Jul 2012 11:33:17 +0400:
> 
>> On Wed, 25 Jul 2012 11:04:05 +0400, Vasiliy Molostov wrote:
>>
>>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН  
>>> Wed,
>>> 25 Jul 2012 10:32:05 +0400:
>>>
>>>>> If you can synchronize representations, you are a god of time
>>>>> representations.
>>>>
>>>> Synchronization does not necessarily means that you control the clocks.
>>>
>>> Do you see the terminology diff: "time represented"  and "time valued"?
>>> Why you insist on false obvious mistake you follow due to this  
>>> difference?
>>
>> There is certainly no such thing as "time value." What is the point?
> 
> It is the source of time representation.

The representation is determined by the clock. So?

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Wed,  
25 Jul 2012 12:30:21 +0400:
>>> There is certainly no such thing as "time value." What is the point?
>>
>> It is the source of time representation.
>
> The representation is determined by the clock. So?

representation is determined by who screwing clock, man. the question I  
suppose is not ada specific.



-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Wed, 25 Jul 2012 12:45:16 +0400, Vasiliy Molostov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Wed,  
> 25 Jul 2012 12:30:21 +0400:
>>>> There is certainly no such thing as "time value." What is the point?
>>>
>>> It is the source of time representation.
>>
>> The representation is determined by the clock. So?
> 
> representation is determined by who screwing clock, man.

Irrelevant. If anybody does something with the clock that is how the clock
works.

> the question I suppose is not ada specific.

That depends on the question.

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

Re: Ada.Calendar and NTP (and Unix Epoch)

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Of course, if you are worried about leap seconds, you are in for a
> world of pain either way.

But since the time received via NTP is UTC *now* and
Ada.Calendar.Time_Zones.UTC_Time_Offset allows you to convert
Ada.Calendar.Clock times to UTC *now*, I think you should ignore all
posts about political time vs GMT vs UTC.

Unless you are really concerned about time intervals of years.

Re: Ada.Calendar and NTP (and Unix Epoch)

[Dmitry A. Kazakov]

On Wed, 25 Jul 2012 11:14:44 +0100, Simon Wright wrote:

> Unless you are really concerned about time intervals of years.

Of weeks you should say. The last leap second happened June 30 this year.

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