* Re: Windows file timestamp converted to local time
2023-10-17 14:13 0% ` Matt Borchers
@ 2023-10-17 16:28 0% ` Niklas Holsti
0 siblings, 0 replies; 63+ results
From: Niklas Holsti @ 2023-10-17 16:28 UTC (permalink / raw)
On 2023-10-17 17:13, Matt Borchers wrote:
> On Monday, October 16, 2023 at 2:49:52 PM UTC-4, Niklas Holsti wrote:
>> On 2023-10-16 21:35, Matt Borchers wrote:
>>> Below is the function from System.OS_Lib.
>>> Does anybody know where the C implementation can be found?
>>> Does anybody know where the C implementation of "localtime" is found?
>>>
>>> function File_Time_Stamp (Name : C_File_Name) return OS_Time is
>>> function File_Time (Name : Address) return OS_Time;
>>> pragma Import (C, File_Time, "__gnat_file_time_name");
>>> begin
>>> return File_Time (Name);
>>> end File_Time_Stamp;
>> (This question seems to be a follow-up ("Re:") to some earlier post, but
>> my newsreader does not seem to find or show that earlier post.)
>>
>> What is the problem?
>>
>> Have you tried using the standard Ada services:
>> Ada.Directories.Modification_Time and
>> Ada.Calendar.Time_Zones.Local_Time_Offset?
>
> Thank you for the suggestion of using "Ada.Directories.Modification_Time".
Happy to help!
> I didn't think to look in that package.
Ada.Directories does, IMO, seem the best place for it, since it should
not depend on the type of the file -- text, sequential, etc.
> This function adjusts for daylight savings time and returns the time
> as displayed in Windows Explorer.
>
> There needs to be better comments (and documentation) for these time
> related functions. It is often not clear what time is returned.
Yes, but some of that documentation should not be in the Ada standard,
but in the compiler's documentation.
Ada.Directories.Modification_Time returns a value of type
Ada.Calendar.Time. However, "the time base associated with the type Time
of package Calendar is implementation defined" (RM 9.6(23)) so it should
be documented in the implementation documents, that is in the GNAT
documentation. Have you looked there?
^ permalink raw reply [relevance 0%]
* Re: Windows file timestamp converted to local time
2023-10-16 18:49 6% ` Niklas Holsti
2023-10-17 2:39 0% ` Randy Brukardt
@ 2023-10-17 14:13 0% ` Matt Borchers
2023-10-17 16:28 0% ` Niklas Holsti
1 sibling, 1 reply; 63+ results
From: Matt Borchers @ 2023-10-17 14:13 UTC (permalink / raw)
On Monday, October 16, 2023 at 2:49:52 PM UTC-4, Niklas Holsti wrote:
> On 2023-10-16 21:35, Matt Borchers wrote:
> > Below is the function from System.OS_Lib.
> > Does anybody know where the C implementation can be found?
> > Does anybody know where the C implementation of "localtime" is found?
> >
> > function File_Time_Stamp (Name : C_File_Name) return OS_Time is
> > function File_Time (Name : Address) return OS_Time;
> > pragma Import (C, File_Time, "__gnat_file_time_name");
> > begin
> > return File_Time (Name);
> > end File_Time_Stamp;
> (This question seems to be a follow-up ("Re:") to some earlier post, but
> my newsreader does not seem to find or show that earlier post.)
>
> What is the problem?
>
> Have you tried using the standard Ada services:
> Ada.Directories.Modification_Time and
> Ada.Calendar.Time_Zones.Local_Time_Offset?
Thank you for the suggestion of using "Ada.Directories.Modification_Time". I didn't think to look in that package. This function adjusts for daylight savings time and returns the time as displayed in Windows Explorer.
There needs to be better comments (and documentation) for these time related functions. It is often not clear what time is returned. It is safe to assume UTC or local time, but the daylight savings issue caused confusion.
^ permalink raw reply [relevance 0%]
* Re: Windows file timestamp converted to local time
2023-10-16 18:49 6% ` Niklas Holsti
@ 2023-10-17 2:39 0% ` Randy Brukardt
2023-10-17 14:13 0% ` Matt Borchers
1 sibling, 0 replies; 63+ results
From: Randy Brukardt @ 2023-10-17 2:39 UTC (permalink / raw)
"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:kp5eucFogqpU1@mid.individual.net...
> On 2023-10-16 21:35, Matt Borchers wrote:
>> Below is the function from System.OS_Lib.
>> Does anybody know where the C implementation can be found?
>> Does anybody know where the C implementation of "localtime" is found?
>>
>> function File_Time_Stamp (Name : C_File_Name) return OS_Time is
>> function File_Time (Name : Address) return OS_Time;
>> pragma Import (C, File_Time, "__gnat_file_time_name");
>> begin
>> return File_Time (Name);
>> end File_Time_Stamp;
>
>
> (This question seems to be a follow-up ("Re:") to some earlier post, but
> my newsreader does not seem to find or show that earlier post.)
>
> What is the problem?
>
> Have you tried using the standard Ada services:
> Ada.Directories.Modification_Time and
> Ada.Calendar.Time_Zones.Local_Time_Offset?
...as those will work on (almost) any target system, while the actual
implementation is going to be rather OS-dependent. And there never is a good
reason to use a GNAT-only (or any compiler-specific, for any compiler)
facility when there is an equivalent standard facility. Most of those
facilities pre-date the Ada ones.
Randy.
^ permalink raw reply [relevance 0%]
* Re: Windows file timestamp converted to local time
@ 2023-10-16 18:49 6% ` Niklas Holsti
2023-10-17 2:39 0% ` Randy Brukardt
2023-10-17 14:13 0% ` Matt Borchers
0 siblings, 2 replies; 63+ results
From: Niklas Holsti @ 2023-10-16 18:49 UTC (permalink / raw)
On 2023-10-16 21:35, Matt Borchers wrote:
> Below is the function from System.OS_Lib.
> Does anybody know where the C implementation can be found?
> Does anybody know where the C implementation of "localtime" is found?
>
> function File_Time_Stamp (Name : C_File_Name) return OS_Time is
> function File_Time (Name : Address) return OS_Time;
> pragma Import (C, File_Time, "__gnat_file_time_name");
> begin
> return File_Time (Name);
> end File_Time_Stamp;
(This question seems to be a follow-up ("Re:") to some earlier post, but
my newsreader does not seem to find or show that earlier post.)
What is the problem?
Have you tried using the standard Ada services:
Ada.Directories.Modification_Time and
Ada.Calendar.Time_Zones.Local_Time_Offset?
^ permalink raw reply [relevance 6%]
* Re: Problem with emacs ada-mode-7.1.4
@ 2021-07-18 9:26 5% ` Paul Onions
0 siblings, 0 replies; 63+ results
From: Paul Onions @ 2021-07-18 9:26 UTC (permalink / raw)
Hi Dmitry,
On Sunday, 18 July 2021 at 10:00:43 UTC+1, Dmitry A. Kazakov wrote:
> https://www.adaic.org/resources/add_content/standards/05rm/html/RM-9-6-1.html#I3765
That's interesting, so it's in Ada.Calendar.Time_Zones from Ada2005, but that is not one of the packages USEd by gnatcoll-sql_impl.adb. So I'm guessing it was added to one of the GNAT packages later.
Anyway, I cloned the gnatcoll-db git repository and found a "20-sustained" branch in there. Switching to it then allowed me to build gnatcoll_sqlite with GNAT CE 2020. Yay.
However, trying to build gnatcoll_xref failed because it's looking for something called gnatcoll_iconv, which I don't see anywhere in the repository. Need to go looking for that now (or rather later, when I've more time)...
Paul
^ permalink raw reply [relevance 5%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
@ 2020-03-03 14:53 9% ` Simon Wright
1 sibling, 0 replies; 63+ results
From: Simon Wright @ 2020-03-03 14:53 UTC (permalink / raw)
Marius Amado-Alves <amado.alves@gmail.com> writes:
> Feeding Ada.Calendar.Formatting.Image with an Ada.Calendar.Time_Of the
> year, month, day, seconds on the left, we get the image on the
> right. Some images, marked *, are 1 hour behind.
>
> 2015 1 21 32040 ( 8:54 AM) => 2015-01-21 08:54:00
> 2015 1 21 39240 (10:54 AM) => 2015-01-21 10:54:00
> 2015 7 21 32040 ( 8:54 AM) => 2015-07-21 07:54:00 *
> 2015 7 21 39240 (10:54 AM) => 2015-07-21 09:54:00 *
>
> The different input is the month, January versus July, so it looks
> like a daylight savings thing. Is this expected behaviour? Thanks.
>
> [Compiler = GNAT Community 2018 (20180523-73)]
There was a conversation on Ada-Comment in June last year, in which it
turned out that compiler implementers may have have been misinterpreting
the ARM. It was quite confusing.
Part of the problem is that Ada.Calendar.Clock, implemented over the OS
facilities, may or may not be in local time; and how does it treat times
which are not in the 'now' time zone?
I wrote this:
with Ada.Calendar.Formatting;
with Ada.Calendar.Time_Zones;
with Ada.Text_IO;
procedure Marius is
use type Ada.Calendar.Time;
Earlier : constant Ada.Calendar.Time
:= Ada.Calendar.Time_Of (2015, 1, 21, 32040.0);
Later : constant Ada.Calendar.Time
:= Ada.Calendar.Time_Of (2015, 7, 21, 32040.0);
Offset_Earlier : constant Ada.Calendar.Time_Zones.Time_Offset
:= Ada.Calendar.Time_Zones.UTC_Time_Offset (Earlier);
Offset_Later : constant Ada.Calendar.Time_Zones.Time_Offset
:= Ada.Calendar.Time_Zones.UTC_Time_Offset (Later);
begin
Ada.Text_Io.Put_Line ("Earlier");
Ada.Text_IO.Put_Line
("UTC_Time_Offset: " & Offset_Earlier'Image);
Ada.Text_IO.Put_Line
("Time_Zone default: "
& Ada.Calendar.Formatting.Image (Earlier));
Ada.Text_IO.Put_Line
("Time_Zone offset: "
& Ada.Calendar.Formatting.Image (Earlier, Time_Zone => Offset_Earlier));
Ada.Text_IO.New_Line;
Ada.Text_IO.Put_Line ("Later");
Ada.Text_IO.Put_Line
("UTC_Time_Offset: " & Offset_Later'Image);
Ada.Text_IO.Put_Line
("Time_Zone default: "
& Ada.Calendar.Formatting.Image (Later));
Ada.Text_IO.Put_Line
("Time_Zone offset: "
& Ada.Calendar.Formatting.Image (Later, Time_Zone => Offset_Later));
end Marius;
and it appears that with GNAT (current free
versions), macOS Mojave, time zone London, Time_Of does something
mysterious;it seems that Time_Of looks at the time you specify (08:54)
and thinks to itself, "but the date part shows that's in DST, so the
local clock now (in GMT) would be reading 07:54"
$ ./marius
Earlier
UTC_Time_Offset: 0
Time_Zone default: 2015-01-21 08:54:00
Time_Zone offset: 2015-01-21 08:54:00
Later
UTC_Time_Offset: 60
Time_Zone default: 2015-07-21 07:54:00
Time_Zone offset: 2015-07-21 08:54:00
Just for fun, trying a different time zone (this may well NOT be the
same as actually being in that time zone :)
$ TZ=EST ./marius
Earlier
UTC_Time_Offset: -300
Time_Zone default: 2015-01-21 13:54:00
Time_Zone offset: 2015-01-21 08:54:00
Later
UTC_Time_Offset: -300
Time_Zone default: 2015-07-21 13:54:00
Time_Zone offset: 2015-07-21 08:54:00
Same results on Debian (running in a VM on this Macbook).
^ permalink raw reply [relevance 9%]
* Re: Ada.Calendar.Formatting.Image (or Time_Of) changing the time
@ 2020-03-03 14:25 5% ` Dmitry A. Kazakov
0 siblings, 0 replies; 63+ results
From: Dmitry A. Kazakov @ 2020-03-03 14:25 UTC (permalink / raw)
On 2020-03-03 13:59, Marius Amado-Alves wrote:
> Thanks. I used the default, which is a zero offset, hence my surprise,
Zero means UTC, AFAIK. To get local time you should pass the result of
UTC_Time_Offset from Ada.Calendar.Time_Zones.
> but maybe I am misunderstanding something, date and time is such a complex matter.
Nothing complex, just messed up. The design as I understand it, because
ARM tells nothing about the meaning of Time values, is that you
interpret the value of Time differently in different time zones. It is
done by passing the time zone offset, which itself is a function of time
to add necessary confusion. So Time is kind of simultaneously UTC and
CET and whatever.
The common, sane (and scientific) understanding is that UTC and CET are
different times.
One of the consequences of present design is that you, for example,
could not store local time reading as a compound value. Without a time
offset it has no sense. You also cannot spell Jan 23, 2100 CET, as you
do not know which time offset it will possibly have in 80 years. CET is
a function and not a value. So there is a date and no time.
> (Namely, I dont understand how a "fixed" offset can vary throughout the year.)
Political time jumps twice a year, so the offset does. Formally these
are two different times, e.g. CET and CEST.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 5%]
* Q: Calendar and time zones
@ 2019-04-30 0:58 7% b.mcguinness747
0 siblings, 0 replies; 63+ results
From: b.mcguinness747 @ 2019-04-30 0:58 UTC (permalink / raw)
Section 9.6.1 of the Reference Manual has a note (39) at the bottom of the page that says: "Calling Split on the results of subtracting Duration(UTC_Time_Offset*60) from Clock provides the components (hours, minutes, and so on) of the UTC time. In the United States, for example, UTC_Time_Offset will generally be negative."
But several versions of Split have a Time_Zone argument that defaults to 0, which I interpret as meaning that they default to reporting the time in UTC. Moreover, I wrote a test program that seems to report UTC time properly without subtracting a time zone offset:
with Ada.Calendar, Ada.Calendar.Formatting, Ada.Calendar.Time_Zones, Ada.Text_IO;
procedure timetest is
use Ada.Calendar, Ada.Calendar.Formatting, Ada.Calendar.Time_Zones;
now : Time := Clock;
zone_offset : Time_Offset := UTC_Time_Offset (now);
begin
Ada.Text_IO.Put_Line ("Current time: " & Image (now) & " UTC");
Ada.Text_IO.Put_Line ("Current time: " & Image (now, false, zone_offset) & " local");
Ada.Text_IO.Put_Line ("Time zone offset: " & Time_Offset'Image (zone_offset) & " minutes");
end timetest;
$ timetest
Current time: 2019-04-30 00:55:19 UTC
Current time: 2019-04-29 20:55:19 local
Time zone offset: -240 minutes
Perhaps the comment refers only to versions of Split that do not take a Time_Zone argument.
It would be helpful if the comment in the Reference Manual was rewritten in future editions to indicate more clearly what it means.
--- Brian McGuinness
^ permalink raw reply [relevance 7%]
* Re: Time_Zone-aware Day_of_Week ?
2015-07-13 16:45 7% ` Jeffrey R. Carter
@ 2015-07-16 17:07 0% ` brbarkstrom
0 siblings, 0 replies; 63+ results
From: brbarkstrom @ 2015-07-16 17:07 UTC (permalink / raw)
On Monday, July 13, 2015 at 12:45:48 PM UTC-4, Jeffrey R. Carter wrote:
> On 07/13/2015 06:26 AM, Natasha Kerensikova wrote:
> >
> > Moreover, the description in the ARM of the function is quite terse:
> > "Returns the day of the week for Time. This is based on the Year, Month,
> > and Day values of Time."
>
> Presumably the Year, Month, and Day returned by Ada.Calendar.Split.
>
> > However, all of Year, Month and Day functions do have the Time_Zone
> > argument that Day_of_Week lacks. So which time offset is Day_of_Week
> > supposed to use?
>
> I'd guess the time offset given by Ada.Calendar.Time_Zones.UTC_Time_Offset.
>
> PragmARC.Date_Handler.Day_Of_Week gives you the day of week of any Year, Month,
> and Day CE you care to give it, even for values of Year outside
> Ada.Calendar.Year_Number. It can also give you the day of week for any
> Ada.Calendar.Time, using the Year, Month, and Day returned by Ada.Calendar.Split.
>
> The PragmAda Reusable Components are at
>
> https://pragmada.x10hosting.com/pragmarc.htm
>
> --
> Jeff Carter
> "He that hath no beard is less than a man."
> Much Ado About Nothing
> 132
Depending on the precision you need, it might be worth thinking about
the difference between Civil Time (which uses Year, Month, Day, Hour,
Minute, and Second) and International Atomic Time (TAI - due to French
Standards). TAI tracks seconds and is directly related to
GPS Time and one or two other variants. The standard reference for
these different time systems is Seidelmann, P. K., 2006: Explanatory
Supplement to the Astronomical Almanac, University Science Books,
Sausalito, CA. If you need to calculate time differences frequently
and want to avoid the unpleasantries of having to deal with errors
associated with time zone inputs (or lack thereof), TAI is probably
preferable. This may be important for Fourier analysis of time series,
where the incomensurability of Civil Time can introduces errors into the
frequency spectrum derived from the data. One satellite mission had to
expend a great deal of effort to find that the lack of a common time basis
caused some serious errors in their measurements of the Earth's reflection.
Bruce B.
^ permalink raw reply [relevance 0%]
* Re: Time_Zone-aware Day_of_Week ?
@ 2015-07-13 16:45 7% ` Jeffrey R. Carter
2015-07-16 17:07 0% ` brbarkstrom
0 siblings, 1 reply; 63+ results
From: Jeffrey R. Carter @ 2015-07-13 16:45 UTC (permalink / raw)
On 07/13/2015 06:26 AM, Natasha Kerensikova wrote:
>
> Moreover, the description in the ARM of the function is quite terse:
> "Returns the day of the week for Time. This is based on the Year, Month,
> and Day values of Time."
Presumably the Year, Month, and Day returned by Ada.Calendar.Split.
> However, all of Year, Month and Day functions do have the Time_Zone
> argument that Day_of_Week lacks. So which time offset is Day_of_Week
> supposed to use?
I'd guess the time offset given by Ada.Calendar.Time_Zones.UTC_Time_Offset.
PragmARC.Date_Handler.Day_Of_Week gives you the day of week of any Year, Month,
and Day CE you care to give it, even for values of Year outside
Ada.Calendar.Year_Number. It can also give you the day of week for any
Ada.Calendar.Time, using the Year, Month, and Day returned by Ada.Calendar.Split.
The PragmAda Reusable Components are at
https://pragmada.x10hosting.com/pragmarc.htm
--
Jeff Carter
"He that hath no beard is less than a man."
Much Ado About Nothing
132
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
@ 2012-07-25 10:14 7% ` Simon Wright
0 siblings, 0 replies; 63+ results
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 [relevance 7%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
2012-07-24 19:07 0% ` Adam Beneschan
@ 2012-07-24 20:17 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 63+ results
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 [relevance 0%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
@ 2012-07-24 16:26 6% ` Adam Beneschan
2012-07-24 18:28 0% ` Dmitry A. Kazakov
1 sibling, 1 reply; 63+ results
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 [relevance 6%]
* Re: Ada.Calendar Question
@ 2012-07-20 18:24 7% ` awdorrin
0 siblings, 0 replies; 63+ results
From: awdorrin @ 2012-07-20 18:24 UTC (permalink / raw)
I finally realized that these nested packages are tagged private. Now it makes sense.
It looks like the 'easiest' way for me to get from the stored 'seconds' and 'nanoseconds' is to do the following:
procedure Example( sec : in Integer; nSec : in Integer) is
T : Ada.Calendar.Time;
begin
T := Ada.Calendar.Conversions.To_Ada_Time(0) -- to get epoch
+ Ada.Calendar.Conversions.To_Duration( long(sec), long(nSec));
Put_Line( Ada.Calendar.Formatting.Image(
Date => T, Include_Time_Fraction => True,
Time_Zone => Ada.Calendar.Time_Zones.UTC_Time_Offset(T) );
end Example;
The 'To_Duration' is a bit annoying, requiring withing the 'Interfaces.C' package for the 'long' type, but it does work fine.
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
2012-07-24 16:26 6% ` Adam Beneschan
@ 2012-07-24 18:28 0% ` Dmitry A. Kazakov
2012-07-24 19:07 0% ` Adam Beneschan
0 siblings, 1 reply; 63+ results
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 [relevance 0%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
2012-07-24 18:28 0% ` Dmitry A. Kazakov
@ 2012-07-24 19:07 0% ` Adam Beneschan
2012-07-24 20:17 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 63+ results
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 [relevance 0%]
* Re: Dates and Times in GNAT on Linux
2009-09-13 15:36 7% Dates and Times in GNAT on Linux Marc A. Criley
@ 2009-09-13 16:17 6% ` Dmitry A. Kazakov
0 siblings, 0 replies; 63+ results
From: Dmitry A. Kazakov @ 2009-09-13 16:17 UTC (permalink / raw)
On Sun, 13 Sep 2009 10:36:58 -0500, Marc A. Criley wrote:
> I'm confused about GNAT's implementation of some aspects of date/time
> processing on Linux. I'm running GNAT GPL 2009 on Ubuntu Linux; I also
> live in the US Central Time Zone and Daylight Savings Time is in effect
> as I write this.
>
> This is probably a stupid misunderstanding or mistaken expectations or
> feature misuse on my part, but I would really like to know what's going on.
>
> Basically what I'm trying to do is take the time I got from from
> Ada.Real.Clock and convert it to a date/time rep. The result I'm coming
> up with is always an hour off. (DST effect? Read on...) Code will follow
> in a bit.
>
> I discovered that GNAT's implementation of Ada.Real_Time.Clock returns
> the number of seconds since the UTC epoch start, which is very nice and
> very handy. Using Real_Time.Split I can get that number of seconds into
> a visible type, Seconds_Count.
>
> I can then get the start of the Unix/UTC epoch via:
> UTC_Epoch_Start := Calendar.Time_Of(1970, 1, 1)
> + Duration(Calendar.Time_Zones.UTC_Offset * 60);
> -- For where I live, right now the UTC_Offset is -300 minutes,
> -- i.e. -5 hours.
>
> Adding the Real_Time seconds count (as a Duration) to UTC_Epoch_Start
> gives a Calendar.Time value containing the current UTC time, from which
> I can generate an image...which is an hour off from the correct value.
>
> So I'm thinking it might be a DST problem, but shouldn't the affected
> Calendar procedures be taking that into account?
Hmm, it seems otherwise. It is DST now, and no DST for the time point you
calculated the epoch. So the epoch time is incoherent to the time now. Your
calculation presumes that (T + D1) + D2 = T + (D1 + D2) holds for any T, a
political time and any D1, D2, durations. That is wrong for political time.
(Ada.Calendar arithmetic is broken, when Ada.Calendar.Time is political
time) The problem is that UTC_Offset is not a constant, but itself is a
function of UTC time.
> Maybe my conversion from Real_Time.Time to Calendar.Time is flawed...I
> don't know. Any explanation or clarifications would be much appreciated.
You have to sum all clock skews (forth and back) within the interval
between the epoch and the time being converted. These skews will sum up to
either 0 or 1 hour, or maybe 1 hour + possibly n leap seconds. Not an easy
task.
P.S. I wished Ada.Calendar.Time_Zones weren't broken. This was discussed in
c.l.a. a couple of months ago.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 6%]
* Dates and Times in GNAT on Linux
@ 2009-09-13 15:36 7% Marc A. Criley
2009-09-13 16:17 6% ` Dmitry A. Kazakov
0 siblings, 1 reply; 63+ results
From: Marc A. Criley @ 2009-09-13 15:36 UTC (permalink / raw)
I'm confused about GNAT's implementation of some aspects of date/time
processing on Linux. I'm running GNAT GPL 2009 on Ubuntu Linux; I also
live in the US Central Time Zone and Daylight Savings Time is in effect
as I write this.
This is probably a stupid misunderstanding or mistaken expectations or
feature misuse on my part, but I would really like to know what's going on.
Basically what I'm trying to do is take the time I got from from
Ada.Real.Clock and convert it to a date/time rep. The result I'm coming
up with is always an hour off. (DST effect? Read on...) Code will follow
in a bit.
I discovered that GNAT's implementation of Ada.Real_Time.Clock returns
the number of seconds since the UTC epoch start, which is very nice and
very handy. Using Real_Time.Split I can get that number of seconds into
a visible type, Seconds_Count.
I can then get the start of the Unix/UTC epoch via:
UTC_Epoch_Start := Calendar.Time_Of(1970, 1, 1)
+ Duration(Calendar.Time_Zones.UTC_Offset * 60);
-- For where I live, right now the UTC_Offset is -300 minutes,
-- i.e. -5 hours.
Adding the Real_Time seconds count (as a Duration) to UTC_Epoch_Start
gives a Calendar.Time value containing the current UTC time, from which
I can generate an image...which is an hour off from the correct value.
So I'm thinking it might be a DST problem, but shouldn't the affected
Calendar procedures be taking that into account?
I saw that the Ada.Calendar package body uses a C function,
__gnat_localtime_tzoff(), which has "Parameter 'off' captur[ing] the UTC
offset which is either retrieved from the tm struct or calculated from
the 'timezone' extern and the tm_isdst flag in the tm struct." Looking
at the code for this function it appears that _for_Linux_ the
implementation ignores the "tm_isdst" value and just uses the
"tm_gmtoff" value, while for some other Unices it does look at tm_isdst.
I'd like to think there's a good reason for doing that--including me
being an idiot--but I don't see what's going on. And unfortunately I
don't yet have a support contract with AdaCore :-)
I hacked together some C and Ada examples to illustrate this:
tmt.c:
#include <time.h>
#include <stdio.h>
void tmt_c_time(time_t rt_secs)
{
struct tm *local;
time_t t;
t = time(NULL);
printf("secs %d\n", t);
local = localtime(&t);
printf("Local time and date: %s\n", asctime(local));
local = gmtime(&t);
printf("UTC time and date: %s\n", asctime(local));
t = rt_secs;
printf("rt secs %d (from Ada)\n", t);
local = localtime(&t);
printf("Local time and date: %s\n", asctime(local));
local = gmtime(&t);
printf("UTC time and date: %s\n", asctime(local));
}
$ gcc -c -g tmt.c
tmtada.adb:
with Text_IO; use Text_IO;
with Ada.Real_Time; use Ada.Real_Time;
with Ada.Calendar.Formatting; use Ada.Calendar.Formatting;
with Ada.Calendar.Time_Zones; use Ada.Calendar.Time_Zones;
procedure Tmtada is
T : Time := Clock;
Seconds : Seconds_Count;
Span : Time_Span;
Cal_Time : Ada.Calendar.Time;
UTC_Epoch : Ada.Calendar.Time;
procedure Tmt_C_Time(Rt_Secs : Seconds_Count);
pragma Import(C, Tmt_C_Time, "tmt_c_time");
use Ada.Calendar;
begin
Split(T, Seconds, Span);
Put_Line("Seconds since epoch:" & Seconds'Img);
UTC_Epoch := Ada.Calendar.Time_Of(1970, 1, 1) +
Duration(UTC_Time_Offset * 60);
Cal_Time := UTC_Epoch + Duration(Seconds);
Put_Line("Time Image " & Image(Cal_Time));
New_Line;
Put_Line("Via C...");
Tmt_C_Time(Seconds);
end Tmtada;
$ gnatmake -g tmtada -largs tmt.o
Here's what I get from a run:
[95] Marc say: ./tmtada
Seconds since epoch: 1252855814
Time Image 2009-09-13 16:30:14
Via C...
secs 1252855814
Local time and date: Sun Sep 13 10:30:14 2009
UTC time and date: Sun Sep 13 15:30:14 2009
rt secs 1252855814 (from Ada)
Local time and date: Sun Sep 13 10:30:14 2009
UTC time and date: Sun Sep 13 15:30:14 2009
Maybe my conversion from Real_Time.Time to Calendar.Time is flawed...I
don't know. Any explanation or clarifications would be much appreciated.
Marc A. Criley
Mckae Technologies
www.mckae.com
^ permalink raw reply [relevance 7%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
@ 2009-03-30 19:44 8% ` reinkor
0 siblings, 0 replies; 63+ results
From: reinkor @ 2009-03-30 19:44 UTC (permalink / raw)
Thanks to all. Now I think I got it !
And giving the argument "Time1" to UTC_Time_Offset" like this:
UTC_Time_Offset(Time1)
insted of only UTC_Time_Offset (which is the same
as "UTC_Time_Offset(Clock))", then I get consistency:
Time1: 1970-01-01 00:00:00
Time2: 1969-12-31 23:00:00
UTC_Time_Offset: 60
Lesson learned: "remember the argument for UTC_Time_Offset" ! :-)
reinert
PS, new program code:
-----------------------------------------------------------------------------
with Text_IO;
use Text_IO;
with Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
-- with Ada.Calendar.Aritmetric;
use Ada.Calendar,Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
procedure t1 is
package Int_Io is new Text_IO.Integer_Io (Integer);
use Int_Io;
Time1,Time2 : Time;
begin
Time1 := Value("1970-01-01 00:00:00");
Time2 := Ada.Calendar.Time_Of(1970,1,1,0.0);
Put("Time1: ");Put(Image(Time1));New_Line;
Put("Time2: ");Put(Image(Time2));New_Line;
Put("UTC_Time_Offset: ");Put(Integer(UTC_Time_Offset(Time1)),8);
end t1;
On 30 Mar, 18:52, "Jeffrey R. Carter"
<spam.jrcarter....@nospam.acm.org> wrote:
> reinkor wrote:
> > Time1 := Value("1970-01-01 00:00:00");
> > Time2 := Ada.Calendar.Time_Of(1970,1,1,0.0);
>
> > Put("Time1: ");Put(Image(Time1));New_Line;
> > Put("Time2: ");Put(Image(Time2));New_Line;
>
> > Put("UTC_Time_Offset: ");Put(Integer(UTC_Time_Offset),8);
>
> > This gives the following output on my computer:
>
> > Time1: 1970-01-01 00:00:00
> > Time2: 1969-12-31 23:00:00
> > UTC_Time_Offset: 120
>
> > The first line I now understand reflects that both "Value"
> > and "Image" has parameter Time_Zone = 0 (UTC). I.e. "Time1"
> > can be understood to have value 1970-01-01 00:00:00 (UTC).
> > "But "Time2" is 1970-01-01 00:00:00 *minus* one hour (only), and
> > UTC_Time_Offset = 120 (2 hours).
>
> I suspect you've recently gone on
> daylight-savings/summer/whatever-it's-called-where-you-are time, which is UTC
> +02:00 (120 mins), but on 1970 Jan 01 you were on regular time, which is UTC +01:00.
>
> --
> Jeff Carter
> "I don't know why I ever come in here. The
> flies get the best of everything."
> Never Give a Sucker an Even Break
> 102
^ permalink raw reply [relevance 8%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-30 12:37 8% ` reinkor
@ 2009-03-30 13:45 8% ` John B. Matthews
1 sibling, 0 replies; 63+ results
From: John B. Matthews @ 2009-03-30 13:45 UTC (permalink / raw)
In article
<8aad6593-efb8-441f-9eac-27cf2fe7a124@v38g2000yqb.googlegroups.com>,
reinkor <reinkor@gmail.com> wrote:
> Sorry, I now realized that this was not so intuitive for me.
> Given the following (modified) code:
>
> ------------------------------------------------
> with Text_IO;
> use Text_IO;
>
> with Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
> use Ada.Calendar,Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
>
> procedure t1 is
>
> package Int_Io is new Text_IO.Integer_Io (Integer);
> use Int_Io;
>
> Time1,Time2 : Time;
>
> begin
>
> Time1 := Value("1970-01-01 00:00:00");
> Time2 := Ada.Calendar.Time_Of(1970,1,1,0.0);
>
> Put("Time1: ");Put(Image(Time1));New_Line;
> Put("Time2: ");Put(Image(Time2));New_Line;
>
> Put("UTC_Time_Offset: ");Put(Integer(UTC_Time_Offset),8);
>
> end t1;
> ------------------------------------
>
> This gives the following output on my computer:
>
> Time1: 1970-01-01 00:00:00
> Time2: 1969-12-31 23:00:00
> UTC_Time_Offset: 120
>
> The first line I now understand reflects that both "Value" and
> "Image" has parameter Time_Zone = 0 (UTC). I.e. "Time1" can be
> understood to have value 1970-01-01 00:00:00 (UTC). "But "Time2" is
> 1970-01-01 00:00:00 *minus* one hour (only), and UTC_Time_Offset =
> 120 (2 hours). I would expect that it should be UTC - 2 hours (i.e.
> 1969-12-31 22:00:00 and *not* 1969-12-31 23:00:00) ?
Time1 uses Ada.Calendar.Formatting.Value, with a default Time_Zone of 0.
In contrast, Time2 is the result ofAda.Calendar.Time_Of, which is local
time. I'm guessing you're on Summer (Daylight) time, now; but back on
New Year's day of 1970, you were on standard time.
Here is an example that highlights some of the differences:
with Ada.Calendar; use Ada.Calendar;
with Ada.Calendar.Formatting;
with Ada.Calendar.Time_Zones;
use type Ada.Calendar.Time_Zones.Time_Offset;
with Ada.Text_IO; use Ada.Text_IO;
procedure Times is
T : Time := Clock;
D : Time_Zones.Time_Offset;
begin
D := Time_Zones.UTC_Time_Offset(T);
Put("UTC_Time_Offset: "); Put(D'Img); New_Line;
Put("GMT: "); Put(Formatting.Image(T)); New_Line;
Put("Local: "); Put(Formatting.Image(T, False, D)); New_Line;
Put_Line("--");
T := Time_Of(1970, 1, 1, 0.0);
Put(Formatting.Image(T)); New_Line;
Put(Formatting.Image(T, False, -300)); New_Line;
Put_Line("--");
T := Formatting.Time_Of(1970, 1, 1, 0.0);
Put(Formatting.Image(T)); New_Line;
Put(Formatting.Image(T, False, -300)); New_Line;
Put(Formatting.Image(T, False, +60)); New_Line;
end times;
Here's what I see in a New York time zone:
./times
UTC_Time_Offset: -240
GMT: 2009-03-30 13:43:26
Local: 2009-03-30 09:43:26
--
1970-01-01 05:00:00
1970-01-01 00:00:00
--
1970-01-01 00:00:00
1969-12-31 19:00:00
1970-01-01 01:00:00
> I here fight with my intuition :-)
You may want to use the "use" clause a little more sparingly
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
^ permalink raw reply [relevance 8%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-27 16:58 8% ` Jeffrey R. Carter
2009-03-30 11:27 0% ` reinkor
@ 2009-03-30 12:37 8% ` reinkor
2009-03-30 13:45 8% ` John B. Matthews
1 sibling, 2 replies; 63+ results
From: reinkor @ 2009-03-30 12:37 UTC (permalink / raw)
Sorry, I now realized that this was not so intuitive for me.
Given the following (modified) code:
------------------------------------------------
with Text_IO;
use Text_IO;
with Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
use Ada.Calendar,Ada.Calendar.Formatting,Ada.Calendar.Time_Zones;
procedure t1 is
package Int_Io is new Text_IO.Integer_Io (Integer);
use Int_Io;
Time1,Time2 : Time;
begin
Time1 := Value("1970-01-01 00:00:00");
Time2 := Ada.Calendar.Time_Of(1970,1,1,0.0);
Put("Time1: ");Put(Image(Time1));New_Line;
Put("Time2: ");Put(Image(Time2));New_Line;
Put("UTC_Time_Offset: ");Put(Integer(UTC_Time_Offset),8);
end t1;
------------------------------------
This gives the following output on my computer:
Time1: 1970-01-01 00:00:00
Time2: 1969-12-31 23:00:00
UTC_Time_Offset: 120
The first line I now understand reflects that both "Value"
and "Image" has parameter Time_Zone = 0 (UTC). I.e. "Time1"
can be understood to have value 1970-01-01 00:00:00 (UTC).
"But "Time2" is 1970-01-01 00:00:00 *minus* one hour (only), and
UTC_Time_Offset = 120 (2 hours).
I would expect that it should be UTC - 2 hours
(i.e. 1969-12-31 22:00:00 and *not* 1969-12-31 23:00:00) ?
I here fight with my intuition :-)
reinert
On 27 Mar, 18:58, "Jeffrey R. Carter"
<spam.jrcarter....@nospam.acm.org> wrote:
> reinkor wrote:
> > Time1 := Value("1970-01-01 00:00:00");
> > Put(Image(Time1));New_Line;
> > Put(Image(Ada.Calendar.Time_Of(1970,1,1,Duration(0))));
>
> > 1970-01-01 00:00:00
> > 1969-12-31 23:00:00
>
> > The last output line here reflects the fact that Ada takes
> > "local time" from the computer - and the result would be
> > different if I wait to run my program till next Monday
> > (this weekend we change to summer daylight saving time).
>
> No. It reflects the fact that Image takes an Ada.Calendar.Time_Zones.Time_Offset
> parameter (Time_Zone) that defaults to 0 (UTC). Image is therefore converting
> the supplied time from your computer's offset
> (Ada.Calendar.Time_Zones.UTC_Time_Offset) to the default offset of 0. Your
> offset seems to be 60 (GMT + 1 hr). To get the image of what you passed to it,
> you must specify an offset of UTC_Time_Offset.
>
> The 1st value comes out as expected because Value also takes an
> Ada.Calendar.Time_Zones.Time_Offset parameter (Time_Zone) that defaults to 0
> (UTC). It is therefore taking the supplied string, interpreting it as a time in
> UTC, and converting it to the corresponding time for your computer's offset
> (UTC_Time_Offset). When you pass this time to Image with the default for
> Time_Zone, the conversion is then reversed as described above.
>
> You can compare the representations provided by Image with the values obtained
> by Ada.Calendar.Split to observe the conversions that the operations in
> Ada.Calendar.Formatting perform.
>
> Two comments on your code: "with Ada.Calendar.Formatting;" makes Ada,
> Ada.Calendar, and Ada.Calendar.Formatting visible; there is no need to also with
> Ada.Calendar.
>
> I cannot understand why you would say "Duration (0)" when "0.0" is clearer and
> shorter.
>
> --
> Jeff Carter
> "My mind is a raging torrent, flooded with rivulets of
> thought, cascading into a waterfall of creative alternatives."
> Blazing Saddles
> 89
^ permalink raw reply [relevance 8%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-27 16:58 8% ` Jeffrey R. Carter
@ 2009-03-30 11:27 0% ` reinkor
2009-03-30 12:37 8% ` reinkor
1 sibling, 0 replies; 63+ results
From: reinkor @ 2009-03-30 11:27 UTC (permalink / raw)
Thanks for clarifying.
I thought "Offset" was reletive to UTC - not relative
to the "local" time.
So
Time1 := Value("1970-01-01 00:00:00",Time_Zone => UTC_Time_Offset);
gives UTC for the local "input" time "1970-01-01 00:00:00" ?
How do I best "input"/enter UTC time (so a reader of the program
also understand it - an independent of the computer local time)?
reinert
On 27 Mar, 18:58, "Jeffrey R. Carter"
<spam.jrcarter....@nospam.acm.org> wrote:
> reinkor wrote:
> > Time1 := Value("1970-01-01 00:00:00");
> > Put(Image(Time1));New_Line;
> > Put(Image(Ada.Calendar.Time_Of(1970,1,1,Duration(0))));
>
> > 1970-01-01 00:00:00
> > 1969-12-31 23:00:00
>
> > The last output line here reflects the fact that Ada takes
> > "local time" from the computer - and the result would be
> > different if I wait to run my program till next Monday
> > (this weekend we change to summer daylight saving time).
>
> No. It reflects the fact that Image takes an Ada.Calendar.Time_Zones.Time_Offset
> parameter (Time_Zone) that defaults to 0 (UTC). Image is therefore converting
> the supplied time from your computer's offset
> (Ada.Calendar.Time_Zones.UTC_Time_Offset) to the default offset of 0. Your
> offset seems to be 60 (GMT + 1 hr). To get the image of what you passed to it,
> you must specify an offset of UTC_Time_Offset.
>
> The 1st value comes out as expected because Value also takes an
> Ada.Calendar.Time_Zones.Time_Offset parameter (Time_Zone) that defaults to 0
> (UTC). It is therefore taking the supplied string, interpreting it as a time in
> UTC, and converting it to the corresponding time for your computer's offset
> (UTC_Time_Offset). When you pass this time to Image with the default for
> Time_Zone, the conversion is then reversed as described above.
>
> You can compare the representations provided by Image with the values obtained
> by Ada.Calendar.Split to observe the conversions that the operations in
> Ada.Calendar.Formatting perform.
>
> Two comments on your code: "with Ada.Calendar.Formatting;" makes Ada,
> Ada.Calendar, and Ada.Calendar.Formatting visible; there is no need to also with
> Ada.Calendar.
>
> I cannot understand why you would say "Duration (0)" when "0.0" is clearer and
> shorter.
>
> --
> Jeff Carter
> "My mind is a raging torrent, flooded with rivulets of
> thought, cascading into a waterfall of creative alternatives."
> Blazing Saddles
> 89
^ permalink raw reply [relevance 0%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
@ 2009-03-27 16:58 8% ` Jeffrey R. Carter
2009-03-30 11:27 0% ` reinkor
2009-03-30 12:37 8% ` reinkor
0 siblings, 2 replies; 63+ results
From: Jeffrey R. Carter @ 2009-03-27 16:58 UTC (permalink / raw)
reinkor wrote:
> Time1 := Value("1970-01-01 00:00:00");
> Put(Image(Time1));New_Line;
> Put(Image(Ada.Calendar.Time_Of(1970,1,1,Duration(0))));
>
> 1970-01-01 00:00:00
> 1969-12-31 23:00:00
>
> The last output line here reflects the fact that Ada takes
> "local time" from the computer - and the result would be
> different if I wait to run my program till next Monday
> (this weekend we change to summer daylight saving time).
No. It reflects the fact that Image takes an Ada.Calendar.Time_Zones.Time_Offset
parameter (Time_Zone) that defaults to 0 (UTC). Image is therefore converting
the supplied time from your computer's offset
(Ada.Calendar.Time_Zones.UTC_Time_Offset) to the default offset of 0. Your
offset seems to be 60 (GMT + 1 hr). To get the image of what you passed to it,
you must specify an offset of UTC_Time_Offset.
The 1st value comes out as expected because Value also takes an
Ada.Calendar.Time_Zones.Time_Offset parameter (Time_Zone) that defaults to 0
(UTC). It is therefore taking the supplied string, interpreting it as a time in
UTC, and converting it to the corresponding time for your computer's offset
(UTC_Time_Offset). When you pass this time to Image with the default for
Time_Zone, the conversion is then reversed as described above.
You can compare the representations provided by Image with the values obtained
by Ada.Calendar.Split to observe the conversions that the operations in
Ada.Calendar.Formatting perform.
Two comments on your code: "with Ada.Calendar.Formatting;" makes Ada,
Ada.Calendar, and Ada.Calendar.Formatting visible; there is no need to also with
Ada.Calendar.
I cannot understand why you would say "Duration (0)" when "0.0" is clearer and
shorter.
--
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89
^ permalink raw reply [relevance 8%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-24 10:55 0% ` reinkor
@ 2009-03-24 12:49 0% ` Martin
0 siblings, 0 replies; 63+ results
From: Martin @ 2009-03-24 12:49 UTC (permalink / raw)
On 24 Mar, 10:55, reinkor <rein...@gmail.com> wrote:
> On 24 Mar, 11:07, Martin <martin.do...@btopenworld.com> wrote:
>
>
>
>
>
>
>
> > On 24 Mar, 08:51, reinkor <rein...@gmail.com> wrote:
>
> > > What is the "natural"/best way to make an Ada program
> > > treat time/calendar data in UTC ? The quetion is about
> > > treating old measurements/data tagged with UTC time.
>
> > > I use
>
> > > Offset : Constant Time_Offset := UTC_Time_Offset;
>
> > > and include "Time_Zone=>Offset" in calendar routines
> > > (for example in the functions Time_Of, Split, Value
> > > within the packages Ada.Calendar.Formatting and
> > > Ada.Calendar.Time_Zones).
>
> > > I find this a but "artificial". How should one do it?
>
> > > reinert
>
> > Dmitry raises some issue which I'm sure the ARG are looking at but you
> > _might_ be perfectly ok if all you're doing reading log files, etc and
> > not actually trying to combine this with a clock your program is
> > reading and expecting them to tie together with the time on your wrist
> > watch. And if your log didn't come from a run over summer-time
> > changes, leap seconds etc on an OS that actually dealt with such
> > things.
>
> > Cheers
> > -- Martin
>
> So you say that if I make sure nobody runs my program code
> on an advanced computer over summer-time changes, leap seconds etc
> - my program may go correct ?
Without know what you're doing it's hard to say. If you're just using
UTC as a timetag then absolutely you should be ok.
The problems are when the 'real world' goes and changes what 'time' is
- e.g. clocks going forward and backwards, inserting leap seconds.
These sort of things make sensible time computations hard, e.g. what
does "1:30am" mean if the clocks have gone back an hour for winter at
2am? Is it the first 1:30am or the second that night? (can't remember
if it 2am->1am or 3am->2am or something else but you get the idea).
Also leap seconds are interested into OS tables 'retrospectively' - if
you are interested in the difference between to time and need seconds
or better accuracy you again could be in trouble. Do you know your OS
accounts for leap-seconds? If so, do you know if the leap seconds
table is up-to-date?
Cheers
-- Martin
^ permalink raw reply [relevance 0%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-24 10:07 0% ` Martin
@ 2009-03-24 10:55 0% ` reinkor
2009-03-24 12:49 0% ` Martin
0 siblings, 1 reply; 63+ results
From: reinkor @ 2009-03-24 10:55 UTC (permalink / raw)
On 24 Mar, 11:07, Martin <martin.do...@btopenworld.com> wrote:
> On 24 Mar, 08:51, reinkor <rein...@gmail.com> wrote:
>
>
>
>
>
> > What is the "natural"/best way to make an Ada program
> > treat time/calendar data in UTC ? The quetion is about
> > treating old measurements/data tagged with UTC time.
>
> > I use
>
> > Offset : Constant Time_Offset := UTC_Time_Offset;
>
> > and include "Time_Zone=>Offset" in calendar routines
> > (for example in the functions Time_Of, Split, Value
> > within the packages Ada.Calendar.Formatting and
> > Ada.Calendar.Time_Zones).
>
> > I find this a but "artificial". How should one do it?
>
> > reinert
>
> Dmitry raises some issue which I'm sure the ARG are looking at but you
> _might_ be perfectly ok if all you're doing reading log files, etc and
> not actually trying to combine this with a clock your program is
> reading and expecting them to tie together with the time on your wrist
> watch. And if your log didn't come from a run over summer-time
> changes, leap seconds etc on an OS that actually dealt with such
> things.
>
> Cheers
> -- Martin
So you say that if I make sure nobody runs my program code
on an advanced computer over summer-time changes, leap seconds etc
- my program may go correct ?
reinert
^ permalink raw reply [relevance 0%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-24 8:51 7% Newbie Q: How to program in UTC (time/calendar) ? reinkor
2009-03-24 9:18 0% ` Dmitry A. Kazakov
@ 2009-03-24 10:07 0% ` Martin
2009-03-24 10:55 0% ` reinkor
1 sibling, 1 reply; 63+ results
From: Martin @ 2009-03-24 10:07 UTC (permalink / raw)
On 24 Mar, 08:51, reinkor <rein...@gmail.com> wrote:
> What is the "natural"/best way to make an Ada program
> treat time/calendar data in UTC ? The quetion is about
> treating old measurements/data tagged with UTC time.
>
> I use
>
> Offset : Constant Time_Offset := UTC_Time_Offset;
>
> and include "Time_Zone=>Offset" in calendar routines
> (for example in the functions Time_Of, Split, Value
> within the packages Ada.Calendar.Formatting and
> Ada.Calendar.Time_Zones).
>
> I find this a but "artificial". How should one do it?
>
> reinert
Dmitry raises some issue which I'm sure the ARG are looking at but you
_might_ be perfectly ok if all you're doing reading log files, etc and
not actually trying to combine this with a clock your program is
reading and expecting them to tie together with the time on your wrist
watch. And if your log didn't come from a run over summer-time
changes, leap seconds etc on an OS that actually dealt with such
things.
Cheers
-- Martin
^ permalink raw reply [relevance 0%]
* Re: Newbie Q: How to program in UTC (time/calendar) ?
2009-03-24 8:51 7% Newbie Q: How to program in UTC (time/calendar) ? reinkor
@ 2009-03-24 9:18 0% ` Dmitry A. Kazakov
2009-03-24 10:07 0% ` Martin
1 sibling, 0 replies; 63+ results
From: Dmitry A. Kazakov @ 2009-03-24 9:18 UTC (permalink / raw)
On Tue, 24 Mar 2009 01:51:57 -0700 (PDT), reinkor wrote:
> What is the "natural"/best way to make an Ada program
> treat time/calendar data in UTC ? The quetion is about
> treating old measurements/data tagged with UTC time.
>
> I use
>
> � Offset : Constant Time_Offset := UTC_Time_Offset;
>
> and include "Time_Zone=>Offset" in calendar routines
> (for example in the functions Time_Of, Split, Value
> within �the packages Ada.Calendar.Formatting and
> Ada.Calendar.Time_Zones).
>
> I find this a but "artificial". How should one do it?
Sorry for bringing you bad news, but unfortunately there is no way to
handle UTC in Ada. The standard is broken in this respect. I discussed this
in this group earlier and in Ada-Comment too.
The short answer is that if you wanted to deal with UTC, you should have a
look at the implementation of Ada.Calendar.Time provided by your compiler
and then act accordingly.
A longer answer is that UTC_Time_Offset is not necessarily constant. Thus
your way is possibly wrong. Here we come to the inconsistency of the
standard. How does UTC_Time_Offset depend on Time in its turn depends on
what is *Time*. Your solution presumes that Time is UTC (i.e. UTC +
constant offset). This might be wrong, because the standard gives strong
indications that Time is in fact local time = political time. In this case
the offset would depend on the current UTC, and could not depend on Time as
the function UTC_Time_Offset pretends. Offset is not a function of
political time (it is not a function at all). In short, it is broken.
I cannot tell for sure, but it seems that GNAT implementation is Time =
UTC. I.e. Clock does not jump when daylight saving time comes and thus
Split may yield rubbish...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Newbie Q: How to program in UTC (time/calendar) ?
@ 2009-03-24 8:51 7% reinkor
2009-03-24 9:18 0% ` Dmitry A. Kazakov
2009-03-24 10:07 0% ` Martin
0 siblings, 2 replies; 63+ results
From: reinkor @ 2009-03-24 8:51 UTC (permalink / raw)
What is the "natural"/best way to make an Ada program
treat time/calendar data in UTC ? The quetion is about
treating old measurements/data tagged with UTC time.
I use
Offset : Constant Time_Offset := UTC_Time_Offset;
and include "Time_Zone=>Offset" in calendar routines
(for example in the functions Time_Of, Split, Value
within the packages Ada.Calendar.Formatting and
Ada.Calendar.Time_Zones).
I find this a but "artificial". How should one do it?
reinert
^ permalink raw reply [relevance 7%]
* Re: Inspiration for a better calendar package?
2008-12-15 12:14 0% ` m.collado
@ 2008-12-15 13:35 7% ` Dmitry A. Kazakov
0 siblings, 0 replies; 63+ results
From: Dmitry A. Kazakov @ 2008-12-15 13:35 UTC (permalink / raw)
On Mon, 15 Dec 2008 13:14:48 +0100, m.collado@domain.invalid wrote:
> Dmitry A. Kazakov escribi�:
>> On Mon, 15 Dec 2008 08:45:17 +0100, Wilhelm Spickermann wrote:
>>
>>> Additionally we should have time zone tables (without leap second
>>> information) for political time (also needing the ability to
>>> specify "unknown") to do conversions between "political text
>>> representations of time" and "wall clock" time. It also contains
>>> the completely predefined time zone "UTC".
>>
>> I think it can be done much simpler. Conversion to/from political time
>> should simply take time zone offset as the parameter. This is how presently
>> Ada.Calendar.Formatting does. The package Ada.Calendar.Time_Zones already
>> has all tables behind the function UTC_Time_Offset. The only problem is the
>> argument of the function. It must be UTC time instead of political one.
>
> Things are in fact more complex than that. The "official" or "political"
> time changes not only with the country, but also with the season,
> because of daylight savings. And the summer/winter periods change over
> years for the same country. So we need a complete history record of
> starting/ending daylight savings periods for each year and each country
> to correctly compute "political" times from UTC times. And the timezone,
> or even the calendar of a given country also changes over years.
>
> As an example of the troubles introduced by a ill-designed time
> reporting policy, consider the way modern MS-Windows OSs report file
> timestamps. They suddently change at the last sunday of March and
> October in european countries. I once had a Modula-2 compiler system
> that unexpectedly ceased to work (reporting broken installation) after
> the first winter/summer change when I activated the "Automatic change
> time with winter/summer time".
Exactly. That is why Ada.Calendar.Time_Zones has to be an optional package
when dealing with time. Presently in order to obtain UTC, we need
Time_Zones (assuming that it weren't broken). That is the world turned
upside down.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 7%]
* Re: Inspiration for a better calendar package?
2008-12-15 9:00 6% ` Dmitry A. Kazakov
@ 2008-12-15 12:14 0% ` m.collado
2008-12-15 13:35 7% ` Dmitry A. Kazakov
0 siblings, 1 reply; 63+ results
From: m.collado @ 2008-12-15 12:14 UTC (permalink / raw)
Dmitry A. Kazakov escribi�:
> On Mon, 15 Dec 2008 08:45:17 +0100, Wilhelm Spickermann wrote:
>
>> Dmitry A. Kazakov wrote:
>>
>>> We just do not need political time otherwise than for
>>> formatted text output. ...
Agreed.
>>...
>> Additionally we should have time zone tables (without leap second
>> information) for political time (also needing the ability to
>> specify "unknown") to do conversions between "political text
>> representations of time" and "wall clock" time. It also contains
>> the completely predefined time zone "UTC".
>
> I think it can be done much simpler. Conversion to/from political time
> should simply take time zone offset as the parameter. This is how presently
> Ada.Calendar.Formatting does. The package Ada.Calendar.Time_Zones already
> has all tables behind the function UTC_Time_Offset. The only problem is the
> argument of the function. It must be UTC time instead of political one.
Things are in fact more complex than that. The "official" or "political"
time changes not only with the country, but also with the season,
because of daylight savings. And the summer/winter periods change over
years for the same country. So we need a complete history record of
starting/ending daylight savings periods for each year and each country
to correctly compute "political" times from UTC times. And the timezone,
or even the calendar of a given country also changes over years.
As an example of the troubles introduced by a ill-designed time
reporting policy, consider the way modern MS-Windows OSs report file
timestamps. They suddently change at the last sunday of March and
October in european countries. I once had a Modula-2 compiler system
that unexpectedly ceased to work (reporting broken installation) after
the first winter/summer change when I activated the "Automatic change
time with winter/summer time".
Regards.
--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado
^ permalink raw reply [relevance 0%]
* Re: Inspiration for a better calendar package?
@ 2008-12-15 9:00 6% ` Dmitry A. Kazakov
2008-12-15 12:14 0% ` m.collado
0 siblings, 1 reply; 63+ results
From: Dmitry A. Kazakov @ 2008-12-15 9:00 UTC (permalink / raw)
On Mon, 15 Dec 2008 08:45:17 +0100, Wilhelm Spickermann wrote:
> Dmitry A. Kazakov wrote:
>
>> We just do not need political time otherwise than for
>> formatted text output. It was silly for Ada 2005 to define time
>> arithmetic in terms of political time. Especially because there
>> �simply is no way to define such arithmetic. Since political
>> time increment "+" is not a function of its arguments!
>
> I'd propose using two kinds of time each with an own
> arithmetic -- both of them being not political.
>
> The first one is a somehow physical time, which just counts every
> second occuring in reality. The arithmetic for this one is
> obvious and it should have a fine granularity.
This is Ada.Real_Time.Time. The problem with it is that it does not have
any bias to UTC.
> The second one is a wall clock time with the smallest unit being
> a minute on the wall clock (thus having 59, 60 or 61 seconds
> length). We can define an arithmetic here and it is used to
> specify times related to human activities. This time is used to
> store dates like "second monday after easter 2014 at 10:00 UTC"
> or "every day at 12:00 UTC".
Why cannot you use UTC instead? Political time is a combination of UTC time
and the time zone. The latter is a function that yields the time offset for
each given UTC time value. Yes you could skew the resolution down to the
point where any differences become invisible. What about one year? (:-))
The question what this thing could be used for?
It is a madness to make hour a function of current time and place...
> They should not allow mixed arithmetic and conversions bewteen
> them are only possible as far as our knowledge of leap seconds
> allows. (The leap second information of traditional Unix time
> zone tables is unusable here, since they have no way of
> specifying "unknown leap second".)
>
> Additionally we should have time zone tables (without leap second
> information) for political time (also needing the ability to
> specify "unknown") to do conversions between "political text
> representations of time" and "wall clock" time. It also contains
> the completely predefined time zone "UTC".
I think it can be done much simpler. Conversion to/from political time
should simply take time zone offset as the parameter. This is how presently
Ada.Calendar.Formatting does. The package Ada.Calendar.Time_Zones already
has all tables behind the function UTC_Time_Offset. The only problem is the
argument of the function. It must be UTC time instead of political one.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 6%]
* Re: Platform independent calendar
@ 2008-12-07 19:15 6% ` Dmitry A. Kazakov
0 siblings, 0 replies; 63+ results
From: Dmitry A. Kazakov @ 2008-12-07 19:15 UTC (permalink / raw)
On Sun, 7 Dec 2008 15:43:49 +0000, Mike H wrote:
> I am working (solo) on a signalling related application for a UK
> preserved railway. The system needs to be as near to totally platform
> independent as possible. As I see it, this rules out use of package
> Calendar.
>
> Rather than re-invent a wheel, I would prefer to use a pre-existing
> solution and would be grateful for suggestions.
Oh,well. This is a huge issue. We are developing a portable middleware in
Ada 2005 with the heterogeneous nodes synchronized over the network. For
that we need UTC time stamps.
Our investigation has shown that presently there is no way to make it. To
start with, Ada.Calendar is obviously unusable. You should always use
Ada.Real_Time. With the latter you should take care of clock resolution, it
is quite possible that it turns miserable, and you will need to attune the
OS and/or replace the standard Ada library, as we did. For each platform
write a clock test. Note that your workaround will likely depend on the
processor family. We must have written replacements for Pentium IV and PPC.
Further, Ada.Calendar.Time_Zones is ill-specified and thus unusable as
well. I posted a proposal to fix it to Ada comments, but for now you have
no better choice than to look into the implementation your compiler
provides and then to act accordingly.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Time_Zones
2008-08-09 8:04 6% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
@ 2008-08-14 0:20 6% ` Randy Brukardt
0 siblings, 0 replies; 63+ results
From: Randy Brukardt @ 2008-08-14 0:20 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:18iqoye18iuzu$.jz3bz3dssmhe.dlg@40tude.net...
...
> But in any case, RM should clarify what it means under political time.
> I.e.
> whether T1 = T2 (= truly political time), or not (= hidden UTC time).
We purposely did not answer that question, because compilers do not agree
and the only way to get any agreement at all was to leave it unsatisfied.
Most of the compilers do the former (Janus/Ada certainly does), but there
was a vocal minority that wanted the latter be supported.
You should add this question to the Ada-Comment thread (with an appropriate
example), so we can have that fight all over again. It's important that you
have shown that it may have semantic effects (we were convinced it did not,
so we decided not to answer the question).
Randy.
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Time_Zones
2008-08-09 2:09 5% ` Ada.Calendar.Time_Zones Randy Brukardt
@ 2008-08-09 8:04 6% ` Dmitry A. Kazakov
2008-08-14 0:20 6% ` Ada.Calendar.Time_Zones Randy Brukardt
0 siblings, 1 reply; 63+ results
From: Dmitry A. Kazakov @ 2008-08-09 8:04 UTC (permalink / raw)
On Fri, 8 Aug 2008 21:09:42 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:aht87sie2uac$.ke09vcui32dj.dlg@40tude.net...
>> On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
>>> ...
>>>> But all that stuff like Time_Of etc is not really needed with UTC_Time.
>>>> The package should provide Clock, +, -, <, <=, >, >=:
>>>
>>> I don't see how that could work. How would you display or create a UTC
>>> time?
>>
>> No problem:
>>
>> T : Ada.UTC_Time.Time := ...;
>> P : Ada.Calendar.Time := To_Calendar_Time (T);
>>
>> P is the political time corresponding to T, it is well-defined for each T.
>> P can be used in Ada.Calendar.Split to display T as:
>>
>> August 08, 2008 10:18 (Berlin time)
>>
>> When used in Ada.Calendar.Formatting.Split with
>>
>> Time_Zone => UTC_Time_Offset (T)
>>
>> the display could be:
>>
>> August 08, 2008 09:18 (UTC time)
>
> Sorry, this doesn't make any sense. Your original point, boiled down, is
> that it is never safe to convert from political time to UTC (because of the
> overlaps and holes). But then you go ahead and do exactly that.
It is safe in this case because it uses an external zone offset. The
conversion is unsafe when an attempt is made to determine the offset from
the political time itself. That is inconsistent. But when the offset is
determined by the UTC time, then everything is fine.
> In any case, if you were willing to require that, the current specification
> would work just fine for UTC time (because you could always get the UTC time
> directly from the record). In which case there is no problem, so we don't
> need an additional mechanism.
Yes, this is what GNAT does, at least under Windows.
My proposal would allow to have Ada.Calendar.Time really skewed as
politicians always whished (:-)). E.g.
T : Time := Time_Of (2008, 10, 28, 1.5*3600.0); -- 1h before the skew
then
T1 := T + 1.0*3600.0; -- 28.10.2008 02:30 before skew
T2 := T + 2.0*3600.0; -- 28.10.2008 02:30 after skew
T1 = T2 -- Political arithmetic!
A time defined this way will still be convertible forth and back to UTC
time, if you know the time offset. That is 1h for T1 and 2h for T2.
-----------
But in any case, RM should clarify what it means under political time. I.e.
whether T1 = T2 (= truly political time), or not (= hidden UTC time).
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Time_Zones
2008-08-08 8:48 6% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
@ 2008-08-09 2:09 5% ` Randy Brukardt
2008-08-09 8:04 6% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
0 siblings, 1 reply; 63+ results
From: Randy Brukardt @ 2008-08-09 2:09 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:aht87sie2uac$.ke09vcui32dj.dlg@40tude.net...
> On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
>> ...
>>> But all that stuff like Time_Of etc is not really needed with UTC_Time.
>>> The package should provide Clock, +, -, <, <=, >, >=:
>>
>> I don't see how that could work. How would you display or create a UTC
>> time?
>
> No problem:
>
> T : Ada.UTC_Time.Time := ...;
> P : Ada.Calendar.Time := To_Calendar_Time (T);
>
> P is the political time corresponding to T, it is well-defined for each T.
> P can be used in Ada.Calendar.Split to display T as:
>
> August 08, 2008 10:18 (Berlin time)
>
> When used in Ada.Calendar.Formatting.Split with
>
> Time_Zone => UTC_Time_Offset (T)
>
> the display could be:
>
> August 08, 2008 09:18 (UTC time)
Sorry, this doesn't make any sense. Your original point, boiled down, is
that it is never safe to convert from political time to UTC (because of the
overlaps and holes). But then you go ahead and do exactly that.
You could probably make it work if you somehow required Ada.Calendar.Time to
store UTC time + a time zone converter (that is, it isn't really political
time). But that would force a change in representation for most compiler's
Ada.Calendar.Time type, and most likely an increase in size as well. That
would really mess up existing programs that store binary representations of
Time (as Janus/Ada does internally).
In any case, if you were willing to require that, the current specification
would work just fine for UTC time (because you could always get the UTC time
directly from the record). In which case there is no problem, so we don't
need an additional mechanism.
...
>> Anyway, we should have this discussion on Ada-Comment, where it will get
>> recorded and attached to the eventual AI on the topic.
>
> Has the proposal any chance to made it?
I have no idea. I intend to put the mail and question into an AI and thus it
will be on the agenda in the future. Beyond that I cannot say.
I'm sure this exact proposal has no chance because it doesn't fix anything.
But a proposal that does fix something may be a different animal.
Randy.
^ permalink raw reply [relevance 5%]
* Re: Ada.Calendar.Time_Zones
2008-08-07 22:47 6% ` Ada.Calendar.Time_Zones Randy Brukardt
@ 2008-08-08 8:48 6% ` Dmitry A. Kazakov
2008-08-09 2:09 5% ` Ada.Calendar.Time_Zones Randy Brukardt
0 siblings, 1 reply; 63+ results
From: Dmitry A. Kazakov @ 2008-08-08 8:48 UTC (permalink / raw)
On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
> ...
>> But all that stuff like Time_Of etc is not really needed with UTC_Time.
>> The package should provide Clock, +, -, <, <=, >, >=:
>
> I don't see how that could work. How would you display or create a UTC time?
No problem:
T : Ada.UTC_Time.Time := ...;
P : Ada.Calendar.Time := To_Calendar_Time (T);
P is the political time corresponding to T, it is well-defined for each T.
P can be used in Ada.Calendar.Split to display T as:
August 08, 2008 10:18 (Berlin time)
When used in Ada.Calendar.Formatting.Split with
Time_Zone => UTC_Time_Offset (T)
the display could be:
August 08, 2008 09:18 (UTC time)
Creating UTC time from UTC's Y/M/D/S should go as follows:
To_UTC_Time (Ada.Calendar.Formatting.Time_Of (Y/M/D/S, 0), 0);
> Anyway, we should have this discussion on Ada-Comment, where it will get
> recorded and attached to the eventual AI on the topic.
Has the proposal any chance to made it?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Time_Zones
2008-08-07 8:27 5% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
@ 2008-08-07 22:47 6% ` Randy Brukardt
2008-08-08 8:48 6% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
0 siblings, 1 reply; 63+ results
From: Randy Brukardt @ 2008-08-07 22:47 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
...
> But all that stuff like Time_Of etc is not really needed with UTC_Time.
> The
> package should provide Clock, +, -, <, <=, >, >=:
I don't see how that could work. How would you display or create a UTC time?
I find that most of the time you either want to use one or the other (that
is, either UTC time or local time) exclusively in a single program.
Converting to local time wouldn't work since it would change the time zone.
Anyway, we should have this discussion on Ada-Comment, where it will get
recorded and attached to the eventual AI on the topic.
Randy.
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Time_Zones
2008-08-07 2:52 6% ` Ada.Calendar.Time_Zones Randy Brukardt
@ 2008-08-07 8:27 5% ` Dmitry A. Kazakov
2008-08-07 22:47 6% ` Ada.Calendar.Time_Zones Randy Brukardt
0 siblings, 1 reply; 63+ results
From: Dmitry A. Kazakov @ 2008-08-07 8:27 UTC (permalink / raw)
On Wed, 6 Aug 2008 21:52:53 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:3jxnfgd6m2ff.ca8crnn387m3.dlg@40tude.net...
>> On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net...
>>>> Does anybody know the meaning of the result returned by UTC_Time_Offset?
>>>
>>> It's as the RM says.
>>
>> But how to translate what it says into concrete numbers:
>>
>> UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =?
>>
>> OK, I am posting that to Ada comments as you suggested.
>
> I don't think the RM answers your question, which technically means that it
> is unspecified.
Which perplexes me much. How could it happen that an Ada library function
has undefined behavior.
> It is reasonable to ask if it *ought* to be unspecified,
> which is why I asked you to ask the ARG.
Yes, I did.
>>> It's pretty obvious, though, that there is no way to do this correctly
>>> unless the time type is based on UTC (time-zone-less) time. And because
>>> of
>>> compatibility concerns, the only way to do that is to completely junk
>>> Ada.Calendar and start over, duplicating essentially everything. You're
>>> probably right that we should have done that, but it would always be a
>>> tough
>>> sell (lots of people would say that Ada.Calendar is "good enough") --
>>> which
>>> is why you need to ask this question directly to the ARG. (And get as
>>> many
>>> people as possible to support it, too.) I alone could never produce
>>> critical
>>> mass on this topic.
>>
>> I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic,
>> Ada.Calendar.Formatting are all new packages. All of them have an
>> inconsistent semantics, because Time_Of is necessarily inconsistent [*].
>> Zone offset is simply not a function of the local time. It is of the UTC
>> time.
>
> You'd have to completely duplicate the contents of Ada.Calendar using a new,
> very similar time type that is based on UTC.
Hmm, is Ada.Calendar big? Anyway one didn't hesitate to duplicate most of
it in Ada.Calendar.Arithmetic.
But all that stuff like Time_Of etc is not really needed with UTC_Time. The
package should provide Clock, +, -, <, <=, >, >=:
package Ada.UTC_Time is
type UTC_Time is private;
function Clock return UTC_Time;
function "+" (Left : UTC_Time; Right : Duration) return UTC_Time;
function "+" (Left : Duration; Right : UTC_Time) return UTC_Time;
function "-" (Left : UTC_Time; Right : Duration) return UTC_Time;
function "-" (Left : UTC_Time; UTC_Time : Time) return Duration;
function "<" (Left, Right : UTC_Time) return Boolean;
function "<="(Left, Right : UTC_Time) return Boolean;
function ">" (Left, Right : UTC_Time) return Boolean;
function ">="(Left, Right : UTC_Time) return Boolean;
end Ada.UTC_Time;
That's it.
Then:
package Ada.UTC_Time.Time_Zones is
type Time_Offset is range -28*60 .. 28*60;
-- This is well-defined
function UTC_Time_Offset (Date : UTC_Time := Clock) return Time_Offset;
function To_Calendar_Time (Time : UTC_Time; Time_Zone) return Time;
function To_Calendar_Time (Time : UTC_Time; Time_Zone; Time_Offset)
return Time;
-- Time Zone is always required for the backward conversion
function To_UTC_Time (Time : Time; Time_Zone; Time_Offset)
return Time;
end Ada.UTC_Time.Time_Zones;
I would also like to see conversions between Ada.Real_Time.Time and
UTC_Time.
> The real question is whether the hole is important enough to try to fix
> (given that the fix is going require adding a lot more mechanism). That's a
> question I can't answer.
Our problem is that we need to exchange time-stamped data with the outside
world. So we have to convert UTC forth and back to Ada.Real_Time.Time. It
is to expect that the system might become out of service for when the clock
is adjusted. Considering similar cases, like air flight traffic control
systems dealing with GPS clock etc, I wonder how they would handle that.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 5%]
* Re: Ada.Calendar.Time_Zones
2008-08-05 9:10 14% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
@ 2008-08-07 2:52 6% ` Randy Brukardt
2008-08-07 8:27 5% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
0 siblings, 1 reply; 63+ results
From: Randy Brukardt @ 2008-08-07 2:52 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:3jxnfgd6m2ff.ca8crnn387m3.dlg@40tude.net...
> On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net...
>>> Does anybody know the meaning of the result returned by UTC_Time_Offset?
>>
>> It's as the RM says.
>
> But how to translate what it says into concrete numbers:
>
> UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =?
>
> OK, I am posting that to Ada comments as you suggested.
I don't think the RM answers your question, which technically means that it
is unspecified. It is reasonable to ask if it *ought* to be unspecified,
which is why I asked you to ask the ARG.
>> It's pretty obvious, though, that there is no way to do this correctly
>> unless the time type is based on UTC (time-zone-less) time. And because
>> of
>> compatibility concerns, the only way to do that is to completely junk
>> Ada.Calendar and start over, duplicating essentially everything. You're
>> probably right that we should have done that, but it would always be a
>> tough
>> sell (lots of people would say that Ada.Calendar is "good enough") --
>> which
>> is why you need to ask this question directly to the ARG. (And get as
>> many
>> people as possible to support it, too.) I alone could never produce
>> critical
>> mass on this topic.
>
> I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic,
> Ada.Calendar.Formatting are all new packages. All of them have an
> inconsistent semantics, because Time_Of is necessarily inconsistent [*].
> Zone offset is simply not a function of the local time. It is of the UTC
> time.
You'd have to completely duplicate the contents of Ada.Calendar using a new,
very similar time type that is based on UTC. That would have been a hard
sell (even if it would have made more sense, since Ada.Calendar.Arithmetic
probably would have been included directly as part of it). Your examples
make it clear that we should have done that, but we obviously failed to
notice that what we did instead doesn't quite work.
The real question is whether the hole is important enough to try to fix
(given that the fix is going require adding a lot more mechanism). That's a
question I can't answer.
Randy.
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Time_Zones
2008-08-04 22:12 4% ` Ada.Calendar.Time_Zones Randy Brukardt
@ 2008-08-05 9:10 14% ` Dmitry A. Kazakov
2008-08-07 2:52 6% ` Ada.Calendar.Time_Zones Randy Brukardt
0 siblings, 1 reply; 63+ results
From: Dmitry A. Kazakov @ 2008-08-05 9:10 UTC (permalink / raw)
On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net...
>> Does anybody know the meaning of the result returned by UTC_Time_Offset?
>
> It's as the RM says.
But how to translate what it says into concrete numbers:
UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =?
OK, I am posting that to Ada comments as you suggested.
> It's pretty obvious, though, that there is no way to do this correctly
> unless the time type is based on UTC (time-zone-less) time. And because of
> compatibility concerns, the only way to do that is to completely junk
> Ada.Calendar and start over, duplicating essentially everything. You're
> probably right that we should have done that, but it would always be a tough
> sell (lots of people would say that Ada.Calendar is "good enough") -- which
> is why you need to ask this question directly to the ARG. (And get as many
> people as possible to support it, too.) I alone could never produce critical
> mass on this topic.
I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic,
Ada.Calendar.Formatting are all new packages. All of them have an
inconsistent semantics, because Time_Of is necessarily inconsistent [*].
Zone offset is simply not a function of the local time. It is of the UTC
time.
--------
* without additional parameters.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 14%]
* Re: Ada.Calendar.Time_Zones
2008-08-04 9:31 6% Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-04 13:56 5% ` Ada.Calendar.Time_Zones google1
@ 2008-08-04 22:12 4% ` Randy Brukardt
2008-08-05 9:10 14% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
1 sibling, 1 reply; 63+ results
From: Randy Brukardt @ 2008-08-04 22:12 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net...
> Does anybody know the meaning of the result returned by UTC_Time_Offset?
It's as the RM says. You've asked this question here before, and if you want
a useful answer, you need to ask the ARG by sending a question to
Ada-Comment. It's pointless to ask the question here more than once; if you
don't care enough to ask the question on Ada-Comment, then you are just
trolling. Please don't; we have enough of that here as it is.
...
> P.S. Why not to simply provide Ada.UTC_Time (with conversion to
> Ada.Calendar.Time) instead of this mess?
The short answer is that it wouldn't provide any support for time zones
other than UTC and (unspecified) local time zone.
My original idea was that there would be a UTC_Clock function that returned
the correct time. In particular, I viewed a value of Ada.Calendar.Time as an
absolute time without any knowledge of a time zone. Specifically, value of
Ada.Calendar.Time would represent a value like 09:53:00 August 31 2008 with
no particular time zone implied. That means that all of the other operations
make sense with no extra interpretation.
However, that model didn't fly with some members of the ARG: they view a
value of Ada.Calendar.Time as a particular political time. In that view, a
UTC_Clock and Ada.Calendar.Clock would always return the same (logical)
value, and thus the split and formatting routines would always return the
same answer (the political time). Thus some method is needed to tell the
value what time zone the value is intrepreted to be in.
I think we screwed up by using a visible offset value, however; it should
have been a private type that could work any way the implementation wanted.
Particularly, there should have been constants for UTC and local time, and
then an implementation could add more if they wanted.
It's pretty obvious, though, that there is no way to do this correctly
unless the time type is based on UTC (time-zone-less) time. And because of
compatibility concerns, the only way to do that is to completely junk
Ada.Calendar and start over, duplicating essentially everything. You're
probably right that we should have done that, but it would always be a tough
sell (lots of people would say that Ada.Calendar is "good enough") -- which
is why you need to ask this question directly to the ARG. (And get as many
people as possible to support it, too.) I alone could never produce critical
mass on this topic.
Randy.
^ permalink raw reply [relevance 4%]
* Re: Ada.Calendar.Time_Zones
2008-08-04 14:57 7% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
@ 2008-08-04 20:56 7% ` Maciej Sobczak
0 siblings, 0 replies; 63+ results
From: Maciej Sobczak @ 2008-08-04 20:56 UTC (permalink / raw)
On 4 Sie, 16:57, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> When Difference is calculated between two dates
> within the overlapping hour there are two results.
As long as both are correct, what is the problem? ;-)
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar.Time_Zones
2008-08-04 13:56 5% ` Ada.Calendar.Time_Zones google1
@ 2008-08-04 14:57 7% ` Dmitry A. Kazakov
2008-08-04 20:56 7% ` Ada.Calendar.Time_Zones Maciej Sobczak
0 siblings, 1 reply; 63+ results
From: Dmitry A. Kazakov @ 2008-08-04 14:57 UTC (permalink / raw)
On Mon, 4 Aug 2008 06:56:56 -0700 (PDT), google1@hafdconsulting.com wrote:
> On Aug 4, 4:31 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Does anybody know the meaning of the result returned by UTC_Time_Offset? RM
>> says:
>>
>> "Returns, as a number of minutes, the difference between the
>> implementation-defined time zone of Calendar, and UTC time, at the time
>> Date."
>>
>> This is ill-defined. Political time has overlapping intervals in presence
>> of daylight saving time, when the clock is adjusted backwards.
>
> That definition accounts for DST shifts. It says "at the time
> Date," which means that if the date falls into a period where
> the locale is in a DST shift, it will return the DST offset.
> Otherwise, it will return the ST offset.
Consider 1 Oct, 00:30 on the clock. Is it 30 minutes *after* the shift
(already ST) or 30 minutes *before* the shift (still DST)?
> Well I don't think it's a mess. You can convert to UTC or any other
> timezone very easily by changing the offset.
So far, it is unclear how to do this. The same problem has
Ada.Calendar.Arithmetic. When Difference is calculated between two dates
within the overlapping hour there are two results.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 7%]
* Re: Ada.Calendar.Time_Zones
2008-08-04 9:31 6% Ada.Calendar.Time_Zones Dmitry A. Kazakov
@ 2008-08-04 13:56 5% ` google1
2008-08-04 14:57 7% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-04 22:12 4% ` Ada.Calendar.Time_Zones Randy Brukardt
1 sibling, 1 reply; 63+ results
From: google1 @ 2008-08-04 13:56 UTC (permalink / raw)
On Aug 4, 4:31 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Does anybody know the meaning of the result returned by UTC_Time_Offset? RM
> says:
>
> "Returns, as a number of minutes, the difference between the
> implementation-defined time zone of Calendar, and UTC time, at the time
> Date."
>
> This is ill-defined. Political time has overlapping intervals in presence
> of daylight saving time, when the clock is adjusted backwards.
That definition accounts for DST shifts. It says "at the time
Date," which means that if the date falls into a period where
the locale is in a DST shift, it will return the DST offset.
Otherwise, it will return the ST offset.
Unix systems keep information about historic and future (planned)
shifts in their locale's time offset in the tzdata database. I
suspect Windows and other systems have something similar, so by
using that database it is possible to find the time offset for
any point in the past, as well as predicted ones for points in
the future.
> The overlapping time interval has two differences to the UTC time. So which
> one is returned by UTC_Time_Offset?
>
> Furthermore, some intervals are missing in political time. That is when the
> clock is adjusted forward. What is the difference then? Unknown_Zone_Error?
I'm not aware of what is typically done in such areas. I would
suspect that each differing opinion has its own locale, and the
computer will be configured to use one locale or the other.
> P.S. Why not to simply provide Ada.UTC_Time (with conversion to
> Ada.Calendar.Time) instead of this mess?
Well I don't think it's a mess. You can convert to UTC or any other
timezone very easily by changing the offset. Most internet
communication deals in dates via a UTC offset (typically
in the form +/-HHMM but it's easy to convert from that to
+/-minutes). I can say that dealing with date stamps in the
Basil project would have been *far* more difficult using Ada 95
dates, which are ignorant of differing timezones.
^ permalink raw reply [relevance 5%]
* Ada.Calendar.Time_Zones
@ 2008-08-04 9:31 6% Dmitry A. Kazakov
2008-08-04 13:56 5% ` Ada.Calendar.Time_Zones google1
2008-08-04 22:12 4% ` Ada.Calendar.Time_Zones Randy Brukardt
0 siblings, 2 replies; 63+ results
From: Dmitry A. Kazakov @ 2008-08-04 9:31 UTC (permalink / raw)
Does anybody know the meaning of the result returned by UTC_Time_Offset? RM
says:
"Returns, as a number of minutes, the difference between the
implementation-defined time zone of Calendar, and UTC time, at the time
Date."
This is ill-defined. Political time has overlapping intervals in presence
of daylight saving time, when the clock is adjusted backwards.
The overlapping time interval has two differences to the UTC time. So which
one is returned by UTC_Time_Offset?
Furthermore, some intervals are missing in political time. That is when the
clock is adjusted forward. What is the difference then? Unknown_Zone_Error?
P.S. Why not to simply provide Ada.UTC_Time (with conversion to
Ada.Calendar.Time) instead of this mess?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 6%]
* Re: Missing Ada components in Ubuntu
2008-05-25 15:22 6% Missing Ada components in Ubuntu Adrian Hoe
@ 2008-05-25 18:29 0% ` Sebastien Morand
0 siblings, 0 replies; 63+ results
From: Sebastien Morand @ 2008-05-25 18:29 UTC (permalink / raw)
I just compiled AWS under ubuntu so I can help you.
First, you have to compile gcc-4.3 because you can't compile aws-2.3.0 without
it and there is no package in ubuntu.
To compile gcc, you have to get the sources and configure the stuff be sure, to
compile the ada langueage (it will be shown during configure).
Afterwards you run make bootstrap and that's all.
It's a bit long but it works.
Then to compile aws and any ada stuff with gcc 4.3 you have to configure CC var.
For instance :
export CC=/usr/local/bin/gcc if gcc is installed in /usr/local (default)
I recomand you to compile xmlada and asis if you want to.
The thing is Ada.Calendar.Formatting is a library not implemented but in the
version 4.3 ... so no choice to use it.
I'll be happy to help you in any way if you have any problem compiling this stuff.
And believe me, it worth it :-)
Sebastien
> Hi,
>
> Sorry to trouble you, but I have no idea where I am supposed to post
> this. I have posted in Ubuntu forum and AWS list. I guess it will be
> no harm to post this here.
>
> I was trying to install AWS shared library packages by Ubuntu but it
> seemed there was a broken dependency. So I decided to build AWS
> myself.
>
> I got some errors and apparently, AWS could not find a-calfor.ad[sb]
> (Ada.Calendar.Formatting) and a-catizo.ad[sb]
> (Ada.Calendar.Time_Zones). AWS depends on these to build.
>
> Has anyone successfully build AWS on Ubuntu? Why these Ada packages
> are not included (or left out)? I can find these packages in gnat on
> Mac OS X.
>
> I am using both 32- and 64-bit Hardy Heron. Both gnat-4.1 and gnat-4.2
> have no such packages.
>
> Any ideas?
> --
> Adrian Hoe
> http://adrianhoe.com/adrianhoe/
^ permalink raw reply [relevance 0%]
* Missing Ada components in Ubuntu
@ 2008-05-25 15:22 6% Adrian Hoe
2008-05-25 18:29 0% ` Sebastien Morand
0 siblings, 1 reply; 63+ results
From: Adrian Hoe @ 2008-05-25 15:22 UTC (permalink / raw)
Hi,
Sorry to trouble you, but I have no idea where I am supposed to post
this. I have posted in Ubuntu forum and AWS list. I guess it will be
no harm to post this here.
I was trying to install AWS shared library packages by Ubuntu but it
seemed there was a broken dependency. So I decided to build AWS
myself.
I got some errors and apparently, AWS could not find a-calfor.ad[sb]
(Ada.Calendar.Formatting) and a-catizo.ad[sb]
(Ada.Calendar.Time_Zones). AWS depends on these to build.
Has anyone successfully build AWS on Ubuntu? Why these Ada packages
are not included (or left out)? I can find these packages in gnat on
Mac OS X.
I am using both 32- and 64-bit Hardy Heron. Both gnat-4.1 and gnat-4.2
have no such packages.
Any ideas?
--
Adrian Hoe
http://adrianhoe.com/adrianhoe/
^ permalink raw reply [relevance 6%]
* Re: Getting current date and time
2007-07-22 23:00 7% ` Martin
@ 2007-07-23 15:24 0% ` koburtch
0 siblings, 0 replies; 63+ results
From: koburtch @ 2007-07-23 15:24 UTC (permalink / raw)
On Jul 22, 7:00 pm, Martin <martin.do...@btopenworld.com> wrote:
> On 22 Jul, 22:21, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>
> > It looks like there is no standard package for handling current time
> > and date and operations of these entities.
>
> > What are the available solutions?
>
> > --
> > Maciej Sobczakhttp://www.msobczak.com/
>
> Ada.Calendar
>
> or if you have an Ada2005 compiler
>
> Ada.Calendar + Ada.Calendar.Arithmetic, Ada.Calendar.Formatting and
> Ada.Calendar.Time_Zones
>
> Cheers
> -- Martin
You can see an example in my Big Online Book of Linux Ada Programming
at http://www.pegasoft.ca/boblap.html in Section 12.6.
Ken B.
^ permalink raw reply [relevance 0%]
* Re: Getting current date and time
@ 2007-07-22 23:00 7% ` Martin
2007-07-23 15:24 0% ` koburtch
0 siblings, 1 reply; 63+ results
From: Martin @ 2007-07-22 23:00 UTC (permalink / raw)
On 22 Jul, 22:21, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> It looks like there is no standard package for handling current time
> and date and operations of these entities.
>
> What are the available solutions?
>
> --
> Maciej Sobczakhttp://www.msobczak.com/
Ada.Calendar
or if you have an Ada2005 compiler
Ada.Calendar + Ada.Calendar.Arithmetic, Ada.Calendar.Formatting and
Ada.Calendar.Time_Zones
Cheers
-- Martin
^ permalink raw reply [relevance 7%]
* UTC Time Offset on GNAT 2006 for windows
@ 2006-06-25 12:23 9% Björn
0 siblings, 0 replies; 63+ results
From: Björn @ 2006-06-25 12:23 UTC (permalink / raw)
I'm having problem with UTC_Time_Offset in GNAT GPL 2006 (20060522-34)
for windows.
The following code seems to return the value I expect on my Linux
system. However, on Win 2000 SP4 I get strange values (the loop is
there to show that the value differs between calls). I didn't find
anything in the GNAT documentation suggesting that it should not work.
Can anyone else confirm this behaviour on a Windows box?
with Ada.Text_IO;
with Ada.Calendar;
with Ada.Calendar.Time_Zones;
procedure Time_Zone_Test is
Current_Time : Ada.Calendar.Time := Ada.Calendar.Clock;
begin
for I in 1 .. 2 loop
Ada.Text_IO.Put_Line
(Ada.Calendar.Time_Zones.Time_Offset'Image
(Ada.Calendar.Time_Zones.UTC_Time_Offset (Current_Time)));
end loop;
end Time_Zone_Test;
Best regards,
Björn Holmberg
^ permalink raw reply [relevance 9%]
* Re: Advice on Calendar.Time
2005-11-09 19:37 5% ` brian.b.mcguinness
@ 2005-12-01 0:24 0% ` Randy Brukardt
0 siblings, 0 replies; 63+ results
From: Randy Brukardt @ 2005-12-01 0:24 UTC (permalink / raw)
<brian.b.mcguinness@lmco.com> wrote in message
news:1131565063.972303.313350@g44g2000cwa.googlegroups.com...
> So one approach would be to use Ada.Calendar.Time_Zones as Martin
> suggested, e.g. get
> the time of day from Clock, using Split to divide it into year, month,
> day, and second, then get the time offset (in minutes) from
> UTC_Time_Offset, and convert to GMT accordingly. But the question
> remains of how to deal with leap seconds. (And why does
> UTC_Time_Offset return a value in minutes rather than seconds, which
> would make it more compatible with Split?)
Because it's a separate strongly typed parameter to Split. You're supposed
to directly Split the time value into the parts, not try to adjust them
later. Nor are you supposed to add or subtract this value from a Time
object. (There were some members of the ARG who were very opposed to any
such semantics.)
Randy.
^ permalink raw reply [relevance 0%]
* Re: Advice on Calendar.Time
@ 2005-11-09 19:37 5% ` brian.b.mcguinness
2005-12-01 0:24 0% ` Randy Brukardt
1 sibling, 1 reply; 63+ results
From: brian.b.mcguinness @ 2005-11-09 19:37 UTC (permalink / raw)
So one approach would be to use Ada.Calendar.Time_Zones as Martin
suggested, e.g. get
the time of day from Clock, using Split to divide it into year, month,
day, and second, then get the time offset (in minutes) from
UTC_Time_Offset, and convert to GMT accordingly. But the question
remains of how to deal with leap seconds. (And why does
UTC_Time_Offset return a value in minutes rather than seconds, which
would make it more compatible with Split?)
Astronomers face a similar problem in converting conventional dates and
times to the Julian day number, the number of days since 00:00 GMT on
January 1, 4713 B.C. They have software to keep track of leap seconds
and so on. So you might find something useful in a package of
astronomical subroutines such as SOFA, which is at
http://www.iau-sofa.rl.ac.uk/
(this is in Fortran, not Ada, but it could probably be translated
without too much trouble or Fortran routines might be linked into an
Ada program).
Good luck.
--- Brian
^ permalink raw reply [relevance 5%]
* Re: Advice on Calendar.Time
@ 2005-11-09 7:00 6% ` Martin Dowie
0 siblings, 0 replies; 63+ results
From: Martin Dowie @ 2005-11-09 7:00 UTC (permalink / raw)
REH wrote:
> That's fine. It's consistant. The problem I am having is that there
> is no consistant why to deal with knowing what time zone a particular
> Ada implementation uses for Time, and how to force it to use GMT or
> UTC.
There is now:
Ada.Calendar.Time_Zones
see AI-351 @ http://www.martin.dowie.btinternet.co.uk/ (Win32 only
implementation for that particular package)
Cheers
-- Martin
^ permalink raw reply [relevance 6%]
* Re: Timing Block of GNAT code in milliseconds
2005-04-29 20:52 8% ` Randy Brukardt
@ 2005-04-30 10:02 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 63+ results
From: Dmitry A. Kazakov @ 2005-04-30 10:02 UTC (permalink / raw)
On Fri, 29 Apr 2005 15:52:55 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:10m95m5yelieq$.kj1rktb792s3.dlg@40tude.net...
> ...
>> We need time stamps synchronized across the network. The accuracy of
>> synchronization is the second problem. The first problem is that the very
>> idea of synchronized time stamps cannot be expressed in Ada terms. There is
>> no portable way to get say UTC from either Calendar or Real_Time, or to
>> convert UTC to them.
>
> Of course there is (assuming that you have a compiler that supports the Ada
> 2006 Ada.Calendar.Time_Zone and Ada.Calendar.Formatting.Split packages).
>
> declare
> Now : Ada.Calendar.Time := Ada.Calendar.Clock;
> UTC_Offset : Ada.Calendar.Time_Zones.Time_Offset :=
> Ada.Calendar.Time_Zones.UTC_Time_Offset (Now);
> begin
> Ada.Calendar.Formatting.Split (Now, Time_Zone => UTC_Offset, <other
> parts of the UTC time>);
I do hope that there is a Time_Zone which does mangle time!
> ...
> end;
>
> It's a bit clunky, but that is the price of undoing daylight savings time.
> If your time period is short enough (doesn't cross any hour boundaries in
> the early morning), you can just get the offset once.
>
> And you can use Time_Of with a Time_Zone parameter to construct a value.
It is a perversion. It is local political time which is derived from UTC
not otherwise. Then the time span mandated by Ada.Calendar is too short,
precision is too low (for time stamping accuracy is not an issue.)
BTW I think we could safely replace Ada.Calendar.Clock with UTC clock, but
that would make some elder Ada library implementations illegal.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Timing Block of GNAT code in milliseconds
@ 2005-04-29 20:52 8% ` Randy Brukardt
2005-04-30 10:02 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 63+ results
From: Randy Brukardt @ 2005-04-29 20:52 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:10m95m5yelieq$.kj1rktb792s3.dlg@40tude.net...
...
> We need time stamps synchronized across the network. The accuracy of
> synchronization is the second problem. The first problem is that the very
> idea of synchronized time stamps cannot be expressed in Ada terms. There
is
> no portable way to get say UTC from either Calendar or Real_Time, or to
> convert UTC to them.
Of course there is (assuming that you have a compiler that supports the Ada
2006 Ada.Calendar.Time_Zone and Ada.Calendar.Formatting.Split packages).
declare
Now : Ada.Calendar.Time := Ada.Calendar.Clock;
UTC_Offset : Ada.Calendar.Time_Zones.Time_Offset :=
Ada.Calendar.Time_Zones.UTC_Time_Offset (Now);
begin
Ada.Calendar.Formatting.Split (Now, Time_Zone => UTC_Offset, <other
parts of the UTC time>);
...
end;
It's a bit clunky, but that is the price of undoing daylight savings time.
If your time period is short enough (doesn't cross any hour boundaries in
the early morning), you can just get the offset once.
And you can use Time_Of with a Time_Zone parameter to construct a value.
Randy.
^ permalink raw reply [relevance 8%]
* Re: Inserting Calendar.Time in a database
2004-08-26 9:30 0% ` Dmitry A. Kazakov
@ 2004-08-26 18:55 0% ` Randy Brukardt
0 siblings, 0 replies; 63+ results
From: Randy Brukardt @ 2004-08-26 18:55 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:19pc26q7dwvt2.1fyyqhr5nv5j2$.dlg@40tude.net...
...
> > The point is that you must never save values of UTC_Adjustment, but
rather
> > recalculate them each time. Hopefully the implementation of
> > Ada.Calendar.Time_Zones doesn't make this too expensive.
>
> So UTC_Time_Offset should remember the local zone time adjusting history
> and also foresee all future adjustments? How efficient it would be?
It's just a system call of some sort, its certainly no worse than calling
Clock itself and probably is much better.
> Say, there are 32 1kHz channels, for each value I need a time stamp. A
real-life
> application should convert Ada...Clock to FILETIME. It would using Split +
> the formula for leap years, seconds etc, all that in an interrupt handler?
The overhead of calling Clock is such that it would not make sense to do
this on many existing implementations, even if you use Ada.Real_Time. It
certainly would make no sense on any system built on top of Windows or Unix
or Linux. The adjustment to the local time isn't a big enough portion of
that overhead to matter much.
I would expect that it might be possible on some real-time kernels. For
those, it's clear that Ada.Calendar.Time should be UTC time, and a child
package provided to get the Local_Time_Offset if that is needed. (That
really ought to be required behavior of Calendar, but it's simply too
incompatible - and in the worst way, at run time - to do.)
An alternative (especially in the inprecise requirements that you suggested
in your message) is to figure the time base of Ada.Real_Time, then using
Real_Time for most operations. Indeed, this is exactly how Calendar is
implemented on Janus/Ada and on GNAT for Windows: the system time functions
are used to get the time base, and QueryPerformanceCounter is used to get
high precision time information within that time base. (Of course, the fact
that QueryPerformanceCounter leaps forward many seconds on some hardware is
a problem.) We rebase every 5 minutes to avoid drift problems from using two
separate clocks; I believe GNAT is similar.
In any case, the sorts of requirements that you have are simply not
supportable within the standard. (Or implementations, for that matter.) No
Ada vendor is going to guarantee anything about the accuracy of the time
base (because it's completely out of their control), which is a necessary
parameter in any sort of distributed system. Either it doesn't matter much
(as in HTTP), or you are going to have to take steps to insure that it is
accurate enough, and that requires going beyond anything that the standard
could possibly give you.
Randy.
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
2004-08-26 0:49 7% ` Randy Brukardt
@ 2004-08-26 9:30 0% ` Dmitry A. Kazakov
2004-08-26 18:55 0% ` Randy Brukardt
0 siblings, 1 reply; 63+ results
From: Dmitry A. Kazakov @ 2004-08-26 9:30 UTC (permalink / raw)
On Wed, 25 Aug 2004 19:49:46 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:poqdv57eopmp$.z8pwmifutqaq.dlg@40tude.net...
>> On Tue, 24 Aug 2004 14:25:19 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net...
>>> ...
>>>> I see a problem with it. UTC_Time_Offset is not constant, so there also
>>>> should be an atomic way to get exact UTC. Actually Ada.Real_Time.Time
>>>> seems a better candidate for UTC. I would add it there.
>>>
>>> This is a gross misunderstanding of Ada's clock packages. Ada.Calendar
> is
>>> about time related to an external (standard) timebase, like UTC or CDT.
>>> Ada.Real_Time is about time related to an internal timebase. There is no
>>> defined relationship between Calendar and Real_Time, and that's
> intentional.
>>> Real_Time would typically be implemented with a hardware counter (such
> as
>>> QueryPerformanceCount on Windows).
>>
>> So should UTC clock. The major application area of UTC is time stamping in
>> distributed applications. The requirements on time stamps are very
>> different from of Ada.Calendar.Time.
>
> Of course. "Time stamps" actually have nothing to do with time; the only
> requirement being that they be unique (and in some cases increasing).
> "Time" is usually used as a quick way to get them, but that is often a mistake
> (precision issues, time bases, etc.) It would be better to call them
> "generation stamps" or something like that. Certainly, you can use a UTC
> time to implement a "generation stamp", but it isn't such a thing, and it
> makes no sense to imply that it could be.
No. That would be just a stamp. A time stamp identifies the time of object
creation. One more typical example: you measure some signal and wish to
display it on-line as a wave form on the other side of the globe. Nether
measurement points are equidistant, nor something concrete could be said
about the communication channel.
> Moreover, we don't want to require
> a UTC time base in Ada, because embedded systems may not have access to an
> appropriate time base - and we certainly don't want to insist that every
> system be hooked up to the Internet!
It could be a child package. It could be a separate package described in
the Annex E.
> OTOH, UTC time really is about time (that is, years, months, days, hours,
> minutes, seconds), which makes it exactly appropriate for Ada.Calendar.
Ada.Real_Time is also about time. That you can view a clock reading as
year, month, etc tells nothing about time. It tells only about the time
base of the duration interval the clock return. The "system start" base is
as good as any other.
>> The source of clock synchronization is
>> less important. A pedant would say that the source is always external.
>> Quartz generators are not written in Ada, yet (:-)) It is no matter
>> whether
>> the clock is synchronized with a radio source or an internal quartz. Clock
>> behavior matters.
>
> Yes, it matters a lot. Using locally determined UTC time as a generation
> stamp would be terrible if the systems are not synchronized to the same time
> base. That immediately takes it out the of realm of what the language can
> specify.
Does Ada.Calendar require that? It is quite legal set year 2090 on my
system. Why then Ada.Universal_Time should? We cannot influence the
precision of mapping the time base to UTC. So we should not specify it.
BTW, quite often the precision required for clock synchronization of nodes
is in order of magnitude lower than the required accuracy of clocks. For
example you need one second externally and one microsecond locally.
Essential is range, resolution and backward jumps.
>> For the same reason we have two of them now. The underlying clocks have
>> different behavior. My point is that the nature of UTC clock is closer to
>> one of real-time than to calendar.
>
> You've obviously not had to sit thru hours of arguments with Tucker Taft on
> this topic!
>
> One of the implementation models for Ada.Calendar (and one apparently used
> by SofCheck derived compilers) is that an object of Ada.Calendar.Time is a
> monotomically increasing clock (usually UTC time). Localization is applied
> in Split. The reason for the design of the Ada.Calendar.Time_Zones is so
> that this implementation model can be applied. The important thing to
> realize here is that there is no *requirement* for the *actual* value of
> Ada.Calendar.Time to run backwards. There is no real difference in
> requirements between UTC time and Ada.Calendar.Time. Moreover, there is no
> requirement that Ada.Calendar.Time even default to local time. I think it
> would have been best if it in fact was required to be UTC time, but that
> would not have made sense in 1980 (popular OSes at that time provided no or
> very weak time zone support), and now we have a compatibility problem.
Do you want to strengthen Ada.Calendar requirements?
>>>> It is not warranted [guarenteed] that Clock /= Clock.
>>>
>>> Of course. How could it be? If two calls are sufficiently close
> together,
>>> the clock may not have ticked in the interval. That's true even for
>>> Ada.Real_Time.Clock; it only guarantees never to run backwards.
>>
>> It is a requirement when UTC is used for time stamping. Should
>> Ada.Universal_Time be implemented as a separate package, one could fulfill
>> it. For example, Clock could block until a tick which will change the
>> result. It could be more than one, due to clock synchronization causing
>> ignoring some ticks. Of course Clock should be bounded. Alternatively one
>> could make clock reading artificially by adding "subtick" counter etc.
>
> That's clearly a requirement of your application which has nothing to do
> with the definition of Time. Your "generation stamp" package should be
> designed to guarantee this property if it is needed; it's a rare enough
> requirement that there isn't any reason to build it into the language.
I do not think so. Application areas are: time stamping, time
synchronization in distributed systems, data logging, remote control,
remote data acquisition, communication protocols requiring time.
> Also note that your original complaint is bogus:
>
>> I see a problem with it. UTC_Time_Offset is not constant, so there also
>> should be an atomic way to get exact UTC.
>
> There is, you're just doing the operations in the wrong order:
>
> declare
> A_Time : Ada.Calendar.Time := Ada.Calendar.Clock;
> UTC_Adjustment : Ada.Calendar.Time_Zones.Time_Offset :=
> Ada.Calendar.Time_Zones.UTC_Time_Offset (A_Time);
> begin
> -- Do Split or other operations using UTC_Adjustment.
> end;
>
> The point is that you must never save values of UTC_Adjustment, but rather
> recalculate them each time. Hopefully the implementation of
> Ada.Calendar.Time_Zones doesn't make this too expensive.
So UTC_Time_Offset should remember the local zone time adjusting history
and also foresee all future adjustments? How efficient it would be? Say,
there are 32 1kHz channels, for each value I need a time stamp. A real-life
application should convert Ada...Clock to FILETIME. It would using Split +
the formula for leap years, seconds etc, all that in an interrupt handler?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
@ 2004-08-26 0:49 7% ` Randy Brukardt
2004-08-26 9:30 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 63+ results
From: Randy Brukardt @ 2004-08-26 0:49 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:poqdv57eopmp$.z8pwmifutqaq.dlg@40tude.net...
> On Tue, 24 Aug 2004 14:25:19 -0500, Randy Brukardt wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> > news:1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net...
> > ...
> >> I see a problem with it. UTC_Time_Offset is not constant, so there also
> >> should be an atomic way to get exact UTC. Actually Ada.Real_Time.Time
> >> seems a better candidate for UTC. I would add it there.
> >
> > This is a gross misunderstanding of Ada's clock packages. Ada.Calendar
is
> > about time related to an external (standard) timebase, like UTC or CDT.
> > Ada.Real_Time is about time related to an internal timebase. There is no
> > defined relationship between Calendar and Real_Time, and that's
intentional.
> > Real_Time would typically be implemented with a hardware counter (such
as
> > QueryPerformanceCount on Windows).
>
> So should UTC clock. The major application area of UTC is time stamping in
> distributed applications. The requirements on time stamps are very
> different from of Ada.Calendar.Time.
Of course. "Time stamps" actually have nothing to do with time; the only
requirement being that they be unique (and in some cases increasing). "Time"
is usually used as a quick way to get them, but that is often a mistake
(precision issues, time bases, etc.) It would be better to call them
"generation stamps" or something like that. Certainly, you can use a UTC
time to implement a "generation stamp", but it isn't such a thing, and it
makes no sense to imply that it could be. Moreover, we don't want to require
a UTC time base in Ada, because embedded systems may not have access to an
appropriate time base - and we certainly don't want to insist that every
system be hooked up to the Internet!
OTOH, UTC time really is about time (that is, years, months, days, hours,
minutes, seconds), which makes it exactly appropriate for Ada.Calendar.
> The source of clock synchronization is
> less important. A pedant would say that the source is always external.
> Quartz generators are not written in Ada, yet (:-)) It is no matter
whether
> the clock is synchronized with a radio source or an internal quartz. Clock
> behavior matters.
Yes, it matters a lot. Using locally determined UTC time as a generation
stamp would be terrible if the systems are not synchronized to the same time
base. That immediately takes it out the of realm of what the language can
specify.
> > Moreover, Ada.Real_Time has no concept of dates, which is critical to
using
> > a UTC time. Adding all of that to Ada.Real_Time would just make it a
clone
> > of Calendar, which then would beg the question of why we need two
different
> > time packages.
>
> For the same reason we have two of them now. The underlying clocks have
> different behavior. My point is that the nature of UTC clock is closer to
> one of real-time than to calendar.
You've obviously not had to sit thru hours of arguments with Tucker Taft on
this topic!
One of the implementation models for Ada.Calendar (and one apparently used
by SofCheck derived compilers) is that an object of Ada.Calendar.Time is a
monotomically increasing clock (usually UTC time). Localization is applied
in Split. The reason for the design of the Ada.Calendar.Time_Zones is so
that this implementation model can be applied. The important thing to
realize here is that there is no *requirement* for the *actual* value of
Ada.Calendar.Time to run backwards. There is no real difference in
requirements between UTC time and Ada.Calendar.Time. Moreover, there is no
requirement that Ada.Calendar.Time even default to local time. I think it
would have been best if it in fact was required to be UTC time, but that
would not have made sense in 1980 (popular OSes at that time provided no or
very weak time zone support), and now we have a compatibility problem.
> >> It is not warranted [guarenteed] that Clock /= Clock.
> >
> > Of course. How could it be? If two calls are sufficiently close
together,
> > the clock may not have ticked in the interval. That's true even for
> > Ada.Real_Time.Clock; it only guarantees never to run backwards.
>
> It is a requirement when UTC is used for time stamping. Should
> Ada.Universal_Time be implemented as a separate package, one could fulfill
> it. For example, Clock could block until a tick which will change the
> result. It could be more than one, due to clock synchronization causing
> ignoring some ticks. Of course Clock should be bounded. Alternatively one
> could make clock reading artificially by adding "subtick" counter etc.
That's clearly a requirement of your application which has nothing to do
with the definition of Time. Your "generation stamp" package should be
designed to guarantee this property if it is needed; it's a rare enough
requirement that there isn't any reason to build it into the language.
Also note that your original complaint is bogus:
> I see a problem with it. UTC_Time_Offset is not constant, so there also
should be
> an atomic way to get exact UTC.
There is, you're just doing the operations in the wrong order:
declare
A_Time : Ada.Calendar.Time := Ada.Calendar.Clock;
UTC_Adjustment : Ada.Calendar.Time_Zones.Time_Offset :=
Ada.Calendar.Time_Zones.UTC_Time_Offset (A_Time);
begin
-- Do Split or other operations using UTC_Adjustment.
end;
The point is that you must never save values of UTC_Adjustment, but rather
recalculate them each time. Hopefully the implementation of
Ada.Calendar.Time_Zones doesn't make this too expensive.
Also note that using Tucker's model, you can't apply the adjustment to the
time value, rather it only is used in calls to Split or other formatting
routines. For use a generation stamp, you'll have to reformat this into
something that you can pass around anyway, so that's not a real problem. And
it's no problem to encapsulate all of this into a generation stamp package
that does the needed conversions under the covers -- the best plan in any
case (as you'll need control over the format of the stamps for streaming or
whatever -- you don't want this breaking if you move to a different
compiler).
Randy.
^ permalink raw reply [relevance 7%]
* Re: Inserting Calendar.Time in a database
2004-08-06 9:28 0% ` Martin Dowie
@ 2004-08-06 10:44 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 63+ results
From: Dmitry A. Kazakov @ 2004-08-06 10:44 UTC (permalink / raw)
On Fri, 6 Aug 2004 10:28:58 +0100, Martin Dowie wrote:
> Dmitry A. Kazakov wrote:
>>> Ada.Calendar.Time_Zones might be of use to you. You could store
>>> the value as a string (Ada.Calendar.Formatting).
>>>
>>> See http://www.martin.dowie.btinternet.co.uk/
>>
>> I see a problem with it. UTC_Time_Offset is not constant, so there
>> also should be an atomic way to get exact UTC.
>
> Sorry, not sure what you're getting at here. The UTC_Time_Offset will change
> due to daylight saving, so it can never be a constant.
>
> For Windows, I can't find anything that states if "GetTimeZoneInformation"
> is atomic or not and this is the routine that returns the time structure.
Under Windows I never would use it to get UTC. I would call
QueryPerformanceCounter. Then to convert it to UTC I would use:
[periodically + statistical refinement]
QueryPerformanceCounter 1
GetSystemTimeAsFileTime
QueryPerformanceCounter 2
Mean of 1+2 allows to calculate the offset to UTC epoch. The problem with
using GetSystemTimeAsFileTime alone is that it has a very low resolution,
so one should use some kind of statistical refinement to get closer to
QueryPerformanceCounter accuracy.
> But even if it isn't atomic it's only going to be 'wrong' at most twice a
> year and only for a second or so each time.
Should we shut down the systems for that period of time? (:-)) Then one
cannot deal with past and future times. The time zone itself is not
constant. Governments are very inventive in making our life harder. Time
stamps should be independent on this chaos.
So I am not convinced that Ada.Calendar is a proper place for dealing with
UTC. Time zones are OK there, no question. But similarity between zone
times and UTC is rather apparent. As I said UTC is monotonic, so it should
be Ada.Real_Time.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
2004-08-06 7:48 0% ` Dmitry A. Kazakov
@ 2004-08-06 9:28 0% ` Martin Dowie
2004-08-06 10:44 0% ` Dmitry A. Kazakov
1 sibling, 1 reply; 63+ results
From: Martin Dowie @ 2004-08-06 9:28 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
>> Ada.Calendar.Time_Zones might be of use to you. You could store
>> the value as a string (Ada.Calendar.Formatting).
>>
>> See http://www.martin.dowie.btinternet.co.uk/
>
> I see a problem with it. UTC_Time_Offset is not constant, so there
> also should be an atomic way to get exact UTC.
Sorry, not sure what you're getting at here. The UTC_Time_Offset will change
due to daylight saving, so it can never be a constant.
For Windows, I can't find anything that states if "GetTimeZoneInformation"
is atomic or not and this is the routine that returns the time structure.
But even if it isn't atomic it's only going to be 'wrong' at most twice a
year and only for a second or so each time.
Cheers
-- Martin
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
2004-08-05 21:19 7% ` Martin Dowie
2004-08-06 6:31 0% ` Jano
@ 2004-08-06 7:48 0% ` Dmitry A. Kazakov
2004-08-06 9:28 0% ` Martin Dowie
1 sibling, 2 replies; 63+ results
From: Dmitry A. Kazakov @ 2004-08-06 7:48 UTC (permalink / raw)
On Thu, 5 Aug 2004 21:19:07 +0000 (UTC), Martin Dowie wrote:
> Dmitry A. Kazakov wrote:
>>> I need to insert some timestamps (type Ada.Calendar.Time) in a
>>> database accessed via ODBC using gnade+gnat 3.15p.
>>>
>>> I've looked for timestamp support in the gnade sources without much
>>> luck, I've specially checked the embedded sql support and I haven't
>>> found nothing for this purpose.
>>>
>>> I'm completely clueless about the ODBC client packages so if someone
>>> has done this before (with gesql or directly), a quick pointer for
>>> the things to look at would be great.
>>
>> The problem is that Ada.Calendar.Time is a political time, while
>> persistent time stamps should be UTC or any other absolute time. I
>> know no OS-independent solution for that.
Then quite often one need to pass time stamps across partitions distributed
over different time zones. Presently it is very painful.
> Ada.Calendar.Time_Zones might be of use to you. You could store
> the value as a string (Ada.Calendar.Formatting).
>
> See http://www.martin.dowie.btinternet.co.uk/
I see a problem with it. UTC_Time_Offset is not constant, so there also
should be an atomic way to get exact UTC. Actually Ada.Real_Time.Time seems
a better candidate for UTC. I would add it there. Then why not to provide a
numeric type to be a FILETIME equivalent (64-bit value representing the
number of 100-nanosecond intervals since January 1, 1601)? Alternatively
one could define a full-blown UTC_Time type synchronized with
Ada.Real_Time.Time.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
2004-08-05 21:19 7% ` Martin Dowie
@ 2004-08-06 6:31 0% ` Jano
2004-08-06 7:48 0% ` Dmitry A. Kazakov
1 sibling, 0 replies; 63+ results
From: Jano @ 2004-08-06 6:31 UTC (permalink / raw)
Martin Dowie dice...
> Dmitry A. Kazakov wrote:
> >> I need to insert some timestamps (type Ada.Calendar.Time) in a
> >> database accessed via ODBC using gnade+gnat 3.15p.
> >>
> >> I've looked for timestamp support in the gnade sources without much
> >> luck, I've specially checked the embedded sql support and I haven't
> >> found nothing for this purpose.
> >>
> >> I'm completely clueless about the ODBC client packages so if someone
> >> has done this before (with gesql or directly), a quick pointer for
> >> the things to look at would be great.
> >
> > The problem is that Ada.Calendar.Time is a political time, while
> > persistent time stamps should be UTC or any other absolute time. I
> > know no OS-independent solution for that.
>
> Ada.Calendar.Time_Zones might be of use to you. You could store
> the value as a string (Ada.Calendar.Formatting).
I hadn't thought of time zones and you both are probably right in your
concern, but for now this is a secondary worry. This is for local and
non-critical use. I simply want to have a timestamp in the database
starting from an Ada time type...
Currently I'm doing something similar to the Martin suggestion: instead
of storing a formatted string, I'm storing the seconds elapsed since an
arbitrary epoch.
This is a bit clumsy since I can't work with dates if I want to keep the
queries indexed. I think I'll move to a two-column-with-trigger-on-
insertion setup if no better solution is found.
Thanks!
^ permalink raw reply [relevance 0%]
* Re: Inserting Calendar.Time in a database
@ 2004-08-05 21:19 7% ` Martin Dowie
2004-08-06 6:31 0% ` Jano
2004-08-06 7:48 0% ` Dmitry A. Kazakov
0 siblings, 2 replies; 63+ results
From: Martin Dowie @ 2004-08-05 21:19 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
>> I need to insert some timestamps (type Ada.Calendar.Time) in a
>> database accessed via ODBC using gnade+gnat 3.15p.
>>
>> I've looked for timestamp support in the gnade sources without much
>> luck, I've specially checked the embedded sql support and I haven't
>> found nothing for this purpose.
>>
>> I'm completely clueless about the ODBC client packages so if someone
>> has done this before (with gesql or directly), a quick pointer for
>> the things to look at would be great.
>
> The problem is that Ada.Calendar.Time is a political time, while
> persistent time stamps should be UTC or any other absolute time. I
> know no OS-independent solution for that.
Ada.Calendar.Time_Zones might be of use to you. You could store
the value as a string (Ada.Calendar.Formatting).
See http://www.martin.dowie.btinternet.co.uk/
Cheers
-- Martin
^ permalink raw reply [relevance 7%]
Results 1-63 of 63 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2004-08-05 13:44 Inserting Calendar.Time in a database Jano
2004-08-05 15:21 ` Dmitry A. Kazakov
2004-08-05 21:19 7% ` Martin Dowie
2004-08-06 6:31 0% ` Jano
2004-08-06 7:48 0% ` Dmitry A. Kazakov
2004-08-06 9:28 0% ` Martin Dowie
2004-08-06 10:44 0% ` Dmitry A. Kazakov
2004-08-24 19:25 ` Randy Brukardt
2004-08-25 7:24 ` Dmitry A. Kazakov
2004-08-26 0:49 7% ` Randy Brukardt
2004-08-26 9:30 0% ` Dmitry A. Kazakov
2004-08-26 18:55 0% ` Randy Brukardt
2005-04-21 13:28 Timing Block of GNAT code in milliseconds markp
2005-04-21 18:00 ` tmoran
2005-04-22 1:00 ` Steve
2005-04-23 5:39 ` Simon Wright
2005-04-23 17:49 ` Steve
2005-04-24 18:57 ` Simon Wright
2005-04-24 20:05 ` Dmitry A. Kazakov
2005-04-28 20:26 ` Simon Wright
2005-04-29 8:11 ` Dmitry A. Kazakov
2005-04-29 20:52 8% ` Randy Brukardt
2005-04-30 10:02 0% ` Dmitry A. Kazakov
2005-11-08 16:04 Advice on Calendar.Time REH
2005-11-08 17:09 ` Larry Kilgallen
2005-11-08 17:59 ` Wilhelm Spickermann
2005-11-08 18:38 ` REH
2005-11-08 19:29 ` Martin Dowie
2005-11-08 20:05 ` REH
2005-11-08 22:09 ` Wilhelm Spickermann
2005-11-08 22:13 ` REH
2005-11-09 7:00 6% ` Martin Dowie
2005-11-09 19:37 5% ` brian.b.mcguinness
2005-12-01 0:24 0% ` Randy Brukardt
2006-06-25 12:23 9% UTC Time Offset on GNAT 2006 for windows Björn
2007-07-22 21:21 Getting current date and time Maciej Sobczak
2007-07-22 23:00 7% ` Martin
2007-07-23 15:24 0% ` koburtch
2008-05-25 15:22 6% Missing Ada components in Ubuntu Adrian Hoe
2008-05-25 18:29 0% ` Sebastien Morand
2008-08-04 9:31 6% Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-04 13:56 5% ` Ada.Calendar.Time_Zones google1
2008-08-04 14:57 7% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-04 20:56 7% ` Ada.Calendar.Time_Zones Maciej Sobczak
2008-08-04 22:12 4% ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-05 9:10 14% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-07 2:52 6% ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-07 8:27 5% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-07 22:47 6% ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-08 8:48 6% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-09 2:09 5% ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-09 8:04 6% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-14 0:20 6% ` Ada.Calendar.Time_Zones Randy Brukardt
2008-12-07 15:43 Platform independent calendar Mike H
2008-12-07 19:15 6% ` Dmitry A. Kazakov
2008-12-09 9:48 Inspiration for a better calendar package? Jacob Sparre Andersen
2008-12-09 10:15 ` Martin
2008-12-09 11:15 ` Dmitry A. Kazakov
2008-12-15 7:45 ` Wilhelm Spickermann
2008-12-15 9:00 6% ` Dmitry A. Kazakov
2008-12-15 12:14 0% ` m.collado
2008-12-15 13:35 7% ` Dmitry A. Kazakov
2009-03-24 8:51 7% Newbie Q: How to program in UTC (time/calendar) ? reinkor
2009-03-24 9:18 0% ` Dmitry A. Kazakov
2009-03-24 10:07 0% ` Martin
2009-03-24 10:55 0% ` reinkor
2009-03-24 12:49 0% ` Martin
2009-03-25 21:55 sjw
2009-03-26 1:38 ` tmoran
2009-03-26 20:58 ` sjw
2009-03-27 12:52 ` reinkor
2009-03-27 16:58 8% ` Jeffrey R. Carter
2009-03-30 11:27 0% ` reinkor
2009-03-30 12:37 8% ` reinkor
2009-03-30 13:45 8% ` John B. Matthews
2009-03-30 16:52 ` Jeffrey R. Carter
2009-03-30 19:44 8% ` reinkor
2009-09-13 15:36 7% Dates and Times in GNAT on Linux Marc A. Criley
2009-09-13 16:17 6% ` Dmitry A. Kazakov
2012-07-20 17:18 Ada.Calendar Question awdorrin
2012-07-20 17:59 ` Adam Beneschan
2012-07-20 18:24 7% ` awdorrin
2012-07-23 21:42 Ada.Calendar and NTP (and Unix Epoch) erlo
2012-07-23 22:07 ` Adam Beneschan
2012-07-24 7:24 ` erlo.haugen
2012-07-24 16:26 6% ` Adam Beneschan
2012-07-24 18:28 0% ` Dmitry A. Kazakov
2012-07-24 19:07 0% ` Adam Beneschan
2012-07-24 20:17 0% ` Dmitry A. Kazakov
2012-07-24 20:33 ` Simon Wright
2012-07-25 10:14 7% ` Simon Wright
2015-07-13 13:26 Time_Zone-aware Day_of_Week ? Natasha Kerensikova
2015-07-13 16:45 7% ` Jeffrey R. Carter
2015-07-16 17:07 0% ` brbarkstrom
2019-04-30 0:58 7% Q: Calendar and time zones b.mcguinness747
2020-03-02 18:49 Ada.Calendar.Formatting.Image (or Time_Of) changing the time Marius Amado-Alves
2020-03-02 23:08 ` Randy Brukardt
2020-03-03 12:59 ` Marius Amado-Alves
2020-03-03 14:25 5% ` Dmitry A. Kazakov
2020-03-03 14:53 9% ` Simon Wright
2021-07-17 7:56 Problem with emacs ada-mode-7.1.4 Paul Onions
2021-07-17 21:18 ` Simon Wright
2021-07-18 8:43 ` Paul Onions
2021-07-18 9:00 ` Dmitry A. Kazakov
2021-07-18 9:26 5% ` Paul Onions
[not found] <262bea8c-57ff-480e-b5aa-da94f0436e98n@googlegroups.com>
2023-10-16 18:35 ` Windows file timestamp converted to local time Matt Borchers
2023-10-16 18:49 6% ` Niklas Holsti
2023-10-17 2:39 0% ` Randy Brukardt
2023-10-17 14:13 0% ` Matt Borchers
2023-10-17 16:28 0% ` Niklas Holsti
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox