* Ada.Calendar and NTP (and Unix Epoch) @ 2012-07-23 21:42 erlo 2012-07-23 22:07 ` Adam Beneschan ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: erlo @ 2012-07-23 21:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-23 21:42 Ada.Calendar and NTP (and Unix Epoch) erlo @ 2012-07-23 22:07 ` Adam Beneschan [not found] ` <5s8s08lv6dj1i4tkb99roq9roifsgr44vd@invalid.netcom.com> ` (2 more replies) 2012-07-24 11:34 ` Simon Wright 2012-07-25 2:23 ` sla29970 2 siblings, 3 replies; 39+ messages in thread From: Adam Beneschan @ 2012-07-23 22:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <5s8s08lv6dj1i4tkb99roq9roifsgr44vd@invalid.netcom.com>]
* Re: Ada.Calendar and NTP (and Unix Epoch) [not found] ` <5s8s08lv6dj1i4tkb99roq9roifsgr44vd@invalid.netcom.com> @ 2012-07-24 7:11 ` Dmitry A. Kazakov 2012-07-24 7:50 ` erlo.haugen 0 siblings, 1 reply; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-24 7:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 7:11 ` Dmitry A. Kazakov @ 2012-07-24 7:50 ` erlo.haugen 2012-07-24 8:14 ` Dmitry A. Kazakov 0 siblings, 1 reply; 39+ messages in thread From: erlo.haugen @ 2012-07-24 7:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 7:50 ` erlo.haugen @ 2012-07-24 8:14 ` Dmitry A. Kazakov 2012-07-24 8:34 ` erlo.haugen 0 siblings, 1 reply; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-24 8:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 8:14 ` Dmitry A. Kazakov @ 2012-07-24 8:34 ` erlo.haugen 2012-07-24 9:13 ` Dmitry A. Kazakov 0 siblings, 1 reply; 39+ messages in thread From: erlo.haugen @ 2012-07-24 8:34 UTC (permalink / raw) Cc: mailbox > 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 8:34 ` erlo.haugen @ 2012-07-24 9:13 ` Dmitry A. Kazakov 2012-07-24 12:27 ` erlo.haugen 0 siblings, 1 reply; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-24 9:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 9:13 ` Dmitry A. Kazakov @ 2012-07-24 12:27 ` erlo.haugen 2012-07-24 13:02 ` Dmitry A. Kazakov 2012-07-24 16:37 ` Adam Beneschan 0 siblings, 2 replies; 39+ messages in thread From: erlo.haugen @ 2012-07-24 12:27 UTC (permalink / raw) Cc: mailbox > 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 12:27 ` erlo.haugen @ 2012-07-24 13:02 ` Dmitry A. Kazakov 2012-07-24 14:10 ` erlo 2012-07-24 16:37 ` Adam Beneschan 1 sibling, 1 reply; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-24 13:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 13:02 ` Dmitry A. Kazakov @ 2012-07-24 14:10 ` erlo 0 siblings, 0 replies; 39+ messages in thread From: erlo @ 2012-07-24 14:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 12:27 ` erlo.haugen 2012-07-24 13:02 ` Dmitry A. Kazakov @ 2012-07-24 16:37 ` Adam Beneschan 1 sibling, 0 replies; 39+ messages in thread From: Adam Beneschan @ 2012-07-24 16:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-23 22:07 ` Adam Beneschan [not found] ` <5s8s08lv6dj1i4tkb99roq9roifsgr44vd@invalid.netcom.com> @ 2012-07-24 7:24 ` erlo.haugen 2012-07-24 16:26 ` Adam Beneschan 2012-07-24 20:33 ` Simon Wright 2012-07-24 7:37 ` erlo.haugen 2 siblings, 2 replies; 39+ messages in thread From: erlo.haugen @ 2012-07-24 7:24 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 7:24 ` erlo.haugen @ 2012-07-24 16:26 ` Adam Beneschan 2012-07-24 18:28 ` Dmitry A. Kazakov 2012-07-24 20:33 ` Simon Wright 1 sibling, 1 reply; 39+ messages in thread From: Adam Beneschan @ 2012-07-24 16:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 16:26 ` Adam Beneschan @ 2012-07-24 18:28 ` Dmitry A. Kazakov 2012-07-24 19:07 ` Adam Beneschan 2012-07-24 19:43 ` Vasiliy Molostov 0 siblings, 2 replies; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-24 18:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 18:28 ` Dmitry A. Kazakov @ 2012-07-24 19:07 ` Adam Beneschan 2012-07-24 20:17 ` Dmitry A. Kazakov 2012-07-24 19:43 ` Vasiliy Molostov 1 sibling, 1 reply; 39+ messages in thread From: Adam Beneschan @ 2012-07-24 19:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 19:07 ` Adam Beneschan @ 2012-07-24 20:17 ` Dmitry A. Kazakov 0 siblings, 0 replies; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-24 20:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 18:28 ` Dmitry A. Kazakov 2012-07-24 19:07 ` Adam Beneschan @ 2012-07-24 19:43 ` Vasiliy Molostov 2012-07-24 20:29 ` Dmitry A. Kazakov 1 sibling, 1 reply; 39+ messages in thread From: Vasiliy Molostov @ 2012-07-24 19:43 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 19:43 ` Vasiliy Molostov @ 2012-07-24 20:29 ` Dmitry A. Kazakov 2012-07-24 21:22 ` Vasiliy Molostov 0 siblings, 1 reply; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-24 20:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 20:29 ` Dmitry A. Kazakov @ 2012-07-24 21:22 ` Vasiliy Molostov 2012-07-25 6:32 ` Dmitry A. Kazakov 0 siblings, 1 reply; 39+ messages in thread From: Vasiliy Molostov @ 2012-07-24 21:22 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 21:22 ` Vasiliy Molostov @ 2012-07-25 6:32 ` Dmitry A. Kazakov 2012-07-25 7:04 ` Vasiliy Molostov 0 siblings, 1 reply; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-25 6:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-25 6:32 ` Dmitry A. Kazakov @ 2012-07-25 7:04 ` Vasiliy Molostov 2012-07-25 7:33 ` Dmitry A. Kazakov 0 siblings, 1 reply; 39+ messages in thread From: Vasiliy Molostov @ 2012-07-25 7:04 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-25 7:04 ` Vasiliy Molostov @ 2012-07-25 7:33 ` Dmitry A. Kazakov 2012-07-25 8:05 ` Vasiliy Molostov 0 siblings, 1 reply; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-25 7:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-25 7:33 ` Dmitry A. Kazakov @ 2012-07-25 8:05 ` Vasiliy Molostov 2012-07-25 8:30 ` Dmitry A. Kazakov 0 siblings, 1 reply; 39+ messages in thread From: Vasiliy Molostov @ 2012-07-25 8:05 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-25 8:05 ` Vasiliy Molostov @ 2012-07-25 8:30 ` Dmitry A. Kazakov 2012-07-25 8:45 ` Vasiliy Molostov 0 siblings, 1 reply; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-25 8:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-25 8:30 ` Dmitry A. Kazakov @ 2012-07-25 8:45 ` Vasiliy Molostov 2012-07-25 9:30 ` Dmitry A. Kazakov 0 siblings, 1 reply; 39+ messages in thread From: Vasiliy Molostov @ 2012-07-25 8:45 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-25 8:45 ` Vasiliy Molostov @ 2012-07-25 9:30 ` Dmitry A. Kazakov 0 siblings, 0 replies; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-25 9:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 7:24 ` erlo.haugen 2012-07-24 16:26 ` Adam Beneschan @ 2012-07-24 20:33 ` Simon Wright 2012-07-25 10:14 ` Simon Wright 1 sibling, 1 reply; 39+ messages in thread From: Simon Wright @ 2012-07-24 20:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 20:33 ` Simon Wright @ 2012-07-25 10:14 ` Simon Wright 2012-07-25 13:16 ` Dmitry A. Kazakov 0 siblings, 1 reply; 39+ messages in thread From: Simon Wright @ 2012-07-25 10:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-25 10:14 ` Simon Wright @ 2012-07-25 13:16 ` Dmitry A. Kazakov 0 siblings, 0 replies; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-25 13:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-23 22:07 ` Adam Beneschan [not found] ` <5s8s08lv6dj1i4tkb99roq9roifsgr44vd@invalid.netcom.com> 2012-07-24 7:24 ` erlo.haugen @ 2012-07-24 7:37 ` erlo.haugen 2 siblings, 0 replies; 39+ messages in thread From: erlo.haugen @ 2012-07-24 7:37 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-23 21:42 Ada.Calendar and NTP (and Unix Epoch) erlo 2012-07-23 22:07 ` Adam Beneschan @ 2012-07-24 11:34 ` Simon Wright 2012-07-24 11:59 ` Nasser M. Abbasi 2012-07-25 2:23 ` sla29970 2 siblings, 1 reply; 39+ messages in thread From: Simon Wright @ 2012-07-24 11:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 11:34 ` Simon Wright @ 2012-07-24 11:59 ` Nasser M. Abbasi 2012-07-24 15:08 ` Simon Wright 2012-07-24 19:17 ` John B. Matthews 0 siblings, 2 replies; 39+ messages in thread From: Nasser M. Abbasi @ 2012-07-24 11:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 11:59 ` Nasser M. Abbasi @ 2012-07-24 15:08 ` Simon Wright 2012-07-24 16:59 ` Georg Bauhaus 2012-07-24 19:17 ` John B. Matthews 1 sibling, 1 reply; 39+ messages in thread From: Simon Wright @ 2012-07-24 15:08 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 15:08 ` Simon Wright @ 2012-07-24 16:59 ` Georg Bauhaus 2012-07-24 19:25 ` Simon Wright 0 siblings, 1 reply; 39+ messages in thread From: Georg Bauhaus @ 2012-07-24 16:59 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 16:59 ` Georg Bauhaus @ 2012-07-24 19:25 ` Simon Wright 2012-07-24 22:07 ` Georg Bauhaus 0 siblings, 1 reply; 39+ messages in thread From: Simon Wright @ 2012-07-24 19:25 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 19:25 ` Simon Wright @ 2012-07-24 22:07 ` Georg Bauhaus 0 siblings, 0 replies; 39+ messages in thread From: Georg Bauhaus @ 2012-07-24 22:07 UTC (permalink / raw) 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; } ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-24 11:59 ` Nasser M. Abbasi 2012-07-24 15:08 ` Simon Wright @ 2012-07-24 19:17 ` John B. Matthews 1 sibling, 0 replies; 39+ messages in thread From: John B. Matthews @ 2012-07-24 19:17 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-23 21:42 Ada.Calendar and NTP (and Unix Epoch) erlo 2012-07-23 22:07 ` Adam Beneschan 2012-07-24 11:34 ` Simon Wright @ 2012-07-25 2:23 ` sla29970 2012-07-25 6:40 ` Dmitry A. Kazakov 2 siblings, 1 reply; 39+ messages in thread From: sla29970 @ 2012-07-25 2:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada.Calendar and NTP (and Unix Epoch) 2012-07-25 2:23 ` sla29970 @ 2012-07-25 6:40 ` Dmitry A. Kazakov 0 siblings, 0 replies; 39+ messages in thread From: Dmitry A. Kazakov @ 2012-07-25 6:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2012-07-26 16:15 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-23 21:42 Ada.Calendar and NTP (and Unix Epoch) erlo 2012-07-23 22:07 ` Adam Beneschan [not found] ` <5s8s08lv6dj1i4tkb99roq9roifsgr44vd@invalid.netcom.com> 2012-07-24 7:11 ` Dmitry A. Kazakov 2012-07-24 7:50 ` erlo.haugen 2012-07-24 8:14 ` Dmitry A. Kazakov 2012-07-24 8:34 ` erlo.haugen 2012-07-24 9:13 ` Dmitry A. Kazakov 2012-07-24 12:27 ` erlo.haugen 2012-07-24 13:02 ` Dmitry A. Kazakov 2012-07-24 14:10 ` erlo 2012-07-24 16:37 ` Adam Beneschan 2012-07-24 7:24 ` erlo.haugen 2012-07-24 16:26 ` Adam Beneschan 2012-07-24 18:28 ` Dmitry A. Kazakov 2012-07-24 19:07 ` Adam Beneschan 2012-07-24 20:17 ` Dmitry A. Kazakov 2012-07-24 19:43 ` Vasiliy Molostov 2012-07-24 20:29 ` Dmitry A. Kazakov 2012-07-24 21:22 ` Vasiliy Molostov 2012-07-25 6:32 ` Dmitry A. Kazakov 2012-07-25 7:04 ` Vasiliy Molostov 2012-07-25 7:33 ` Dmitry A. Kazakov 2012-07-25 8:05 ` Vasiliy Molostov 2012-07-25 8:30 ` Dmitry A. Kazakov 2012-07-25 8:45 ` Vasiliy Molostov 2012-07-25 9:30 ` Dmitry A. Kazakov 2012-07-24 20:33 ` Simon Wright 2012-07-25 10:14 ` Simon Wright 2012-07-25 13:16 ` Dmitry A. Kazakov 2012-07-24 7:37 ` erlo.haugen 2012-07-24 11:34 ` Simon Wright 2012-07-24 11:59 ` Nasser M. Abbasi 2012-07-24 15:08 ` Simon Wright 2012-07-24 16:59 ` Georg Bauhaus 2012-07-24 19:25 ` Simon Wright 2012-07-24 22:07 ` Georg Bauhaus 2012-07-24 19:17 ` John B. Matthews 2012-07-25 2:23 ` sla29970 2012-07-25 6:40 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox