* Re: When to use Bounded_String?
@ 2017-12-29 0:42 4% ` Randy Brukardt
0 siblings, 0 replies; 21+ results
From: Randy Brukardt @ 2017-12-29 0:42 UTC (permalink / raw)
"Mehdi Saada" <00120260a@gmail.com> wrote in message
news:158d76ca-7061-400e-8077-222bd4e390d2@googlegroups.com...
> Why hasn't GNATCOLL become part of the standard, since it's made
> by Adacore (correct me if I'm wrong), is alleguedly so better than
> Ada.Strings,
> and since GNAT is now the de-facto only fully-ceritified Ada 2012 compiler
> ?
(1) Adacore has nothing (directly) to do with the Standard, other than
financial support of ARG members.
(2) No one has volunteered to do the work of converting the packages into
the form of Standard. This is a LOT of effort (and I know, having done that
with what became Ada.Directories and Ada.Calendar.Arithmetic -- which
started out life as Claw packages).
(3) Parts of GNATColl are very much dependent on GNAT, while the Standard
remains independent of any particular implementation. (We don't want GNAT to
be the only Ada 2012 compiler forever!)
(4) It's debatable if GNATColl is really better than Ada.Strings.
(5) In general, we've not wanted many different libraries in the Standard
that do the same thing. If a replacement for Ada.Strings was to be adopted,
it would have to provide much better functionality than the existing
libraries, not just a small performance improvement.
Randy.
^ permalink raw reply [relevance 4%]
* Re: ANN: Introducing AdaBase - Thick database bindings for Ada
@ 2016-05-16 20:06 5% ` Randy Brukardt
0 siblings, 0 replies; 21+ results
From: Randy Brukardt @ 2016-05-16 20:06 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]
<gautier_niouzes@hotmail.com> wrote in message
news:f1c76310-e74f-4734-9961-5743e877b5e2@googlegroups.com...
>Le samedi 14 mai 2016 01:37:02 UTC+2, Randy Brukardt a écrit :
>> Impossible, I fear. I tried that with Claw, but even having a several
>> year
>> head start didn't prevent someone from making their own incompatible
>> version.
>
>And in retrospect, it was a good thing: since around 2000, GWindows [1] is
>the only Ada thick binding for Windows maintained, developed, and usable
>for real applications (just tested the 3rd one, JEWL [2]; builds and runs
>fine,
>but very limited beyond demos or toy projects).
Not remotely true (except the point about JEWL - but it was always intended
to be easy rather than powerful).
(1) Plenty of real-world projects use/used Claw - I haven't asked for
permission to talk about customers projects, but we've used it for the
Trash-Finder UI, for the Claw Builder itself (a *very* tough task for an
interface library), and a variety of internal tools.
(2) Claw was actively developed for many years after 2000, and still is
actively maintained now. (Not doing much development because of lack of
demand.)
(3) The above of course is a self-fufilling prophecy; once the split
happened, the community had to make a choice and the effect was to duplicate
all of the effort spent on Claw. The same effort could have been spent on
enhancing Claw and more good stuff would have been available.
At least Claw was not a total waste of time: (1) it toughened up the OOP and
finalization support in Ada compilers, so GWindows and the like were even
possible. (When we started with Claw, most of our code didn't work on early
Ada 95 compilers for one reason or another.) (2) Claw.Directories turned
into Ada.Directories, and Claw.Time turned into Ada.Calendar.Arithmetic and
Ada.Calendar.Formatting - so those things are now available to all Ada
programmers. Too bad that I could never get Ada.Sockets (after Claw.Sockets)
off the ground.
Randy.
^ permalink raw reply [relevance 5%]
* Re: A few questions
@ 2015-11-03 6:25 6% ` Randy Brukardt
0 siblings, 0 replies; 21+ results
From: Randy Brukardt @ 2015-11-03 6:25 UTC (permalink / raw)
"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message
news:n13m1a$p3c$1@dont-email.me...
> On 10/31/2015 01:29 PM, Laurent wrote:
>>
>> I need a range of Dates.
>>
>> So is there an existing package which generates a range of Dates from ..
>> to
>> ?
>>
>> PS: need this range of dates because the log files I want to read and
>> extract
>> informations from are all named like this: vba-yyyymmdd.log where
>> obviously
>> yyyymmdd is the date. The program generates a new file every date an
>> stores
>> the communication it treated in it.
>>
>> I want to read this files and extract the messages which passed. Is more
>> an
>> exercise than actually a need to do it.
>
> I'm not aware of any such pkg. On the other hand, I'm not sure you need
> it. Do
> you really need to store all the dates in the range? You could process the
> file
> for date D, then the file for date D + 1, ..., until you have processed
> all the
> desired files.
>
> Conceptually the idea of an operation
>
> function "+" (Left : in Dates.Object; Right : in Integer) return
> Dates.Object;
>
> makes sense; without knowing the details of the implementation of
> Dates.Object I
> have no idea how easy it would be. For Ada.Calendar.Time, one would simply
> add
> Right * Ada.Calendar.Day_Duration'Last.
Or easier still, just use Ada.Calendar.Arithmetic, which has operations for
adding numbers of days to a Ada.Calendar.Time (added in Ada 2005). (This is
hard to do in Ada 95 if you need to add more than one day at a time.)
Randy.
^ permalink raw reply [relevance 6%]
* Time_Zone-aware Day_of_Week ?
@ 2015-07-13 13:26 5% Natasha Kerensikova
0 siblings, 0 replies; 21+ results
From: Natasha Kerensikova @ 2015-07-13 13:26 UTC (permalink / raw)
Hello,
I was implementing some human time formatting with the help of Ada 2005
standard package Ada.Calendar.Formatting, and realized I have an issue
with the function Day_of_Week with regards to time zone.
Everything else in Ada.Calendar.Formatting seems to support some
user-defined time offset, but not Day_of_Week. Is there a particular
reason for that?
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."
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?
Prying into GNAT's implementation, it seems to use standard system
timezone, but can it be deduced from the ARM?
Is there a workaround to still get a Day_of_Week result that is
consistent with a user-given time offset?
I'm currently leaning towards using Ada.Calendar.Arithmetic.Difference
with a reference date, at midnight in the request time zone, but that
feels a bit inelegant. Is there a better way of doing it?
Thanks for your help,
Natasha
^ permalink raw reply [relevance 5%]
* Re: Ada.Calendar and NTP (and Unix Epoch)
@ 2012-07-24 16:26 5% ` Adam Beneschan
0 siblings, 0 replies; 21+ 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 5%]
* Re: Dates and Times in GNAT on Linux
@ 2009-09-13 16:17 6% ` Dmitry A. Kazakov
0 siblings, 0 replies; 21+ 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%]
* Re: Inspiration for a better calendar package?
2008-12-09 11:15 0% ` Dmitry A. Kazakov
@ 2008-12-09 12:23 0% ` Martin
0 siblings, 0 replies; 21+ results
From: Martin @ 2008-12-09 12:23 UTC (permalink / raw)
On Dec 9, 11:15 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 9 Dec 2008 02:15:55 -0800 (PST), Martin wrote:
> > Ada.Calendar, Ada.Calendar.Arithmetic and Ada.Calender.Time_Zones
> > already seem to provide all this (and more!).
>
> They do not. There is no portable way to handle UTC.
>
> Ada.Calender.Time_Zones and Arithmetic are ill-defined. It was discussed in
> comp.lang.ada in August this year. I also posted a proposal how to fix the
> issue to Ada comment.
>
> As for Ada.Calendar I doubt there should be any. It is a burden inherited
> from Ada 83. 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!
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
Ah, I see there is more to the Haskell library than the initial link
suggests - having found http://haskell.org/ghc/docs/latest/html/libraries/time/Data-Time.html
it does cover the areas I didn't think it did.
If someone thinks this method fixes the perceived problem there is
nothing stopping them creating a "Date_Time" package hierarchy based
on the Haskell library that could be subsequently standardized (into
Ada.Date_Time) - anyone volunteers?
Cheers
-- Martin
^ permalink raw reply [relevance 0%]
* Re: Inspiration for a better calendar package?
2008-12-09 10:15 6% ` Martin
@ 2008-12-09 11:15 0% ` Dmitry A. Kazakov
2008-12-09 12:23 0% ` Martin
0 siblings, 1 reply; 21+ results
From: Dmitry A. Kazakov @ 2008-12-09 11:15 UTC (permalink / raw)
On Tue, 9 Dec 2008 02:15:55 -0800 (PST), Martin wrote:
> Ada.Calendar, Ada.Calendar.Arithmetic and Ada.Calender.Time_Zones
> already seem to provide all this (and more!).
They do not. There is no portable way to handle UTC.
Ada.Calender.Time_Zones and Arithmetic are ill-defined. It was discussed in
comp.lang.ada in August this year. I also posted a proposal how to fix the
issue to Ada comment.
As for Ada.Calendar I doubt there should be any. It is a burden inherited
from Ada 83. 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!
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Inspiration for a better calendar package?
@ 2008-12-09 10:15 6% ` Martin
2008-12-09 11:15 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 21+ results
From: Martin @ 2008-12-09 10:15 UTC (permalink / raw)
On Dec 9, 9:48 am, Jacob Sparre Andersen <spa...@nbi.dk> wrote:
> The last issue of RISKS included a link to a Haskell calendar package:
>
> http://haskell.org/ghc/docs/latest/html/libraries/time/Data-Time-Cloc...
>
> This seems to take the problems related to different kinds of time
> measures slightly more seriously than Ada.Calendar. Should it be
> inspiration for the 201X version of Ada.Calendar?
>
> Greetings,
>
> Jacob
> --
> "You've got to build bypasses!"
Sorry, I must be missing something...
Ada.Calendar, Ada.Calendar.Arithmetic and Ada.Calender.Time_Zones
already seem to provide all this (and more!).
Can you elaborate on what you think is better about the Haskell
version?
Cheers
-- Martin
^ permalink raw reply [relevance 6%]
* Re: Ada.Calendar.Time_Zones
2008-08-07 2:52 5% ` Ada.Calendar.Time_Zones Randy Brukardt
@ 2008-08-07 8:27 5% ` Dmitry A. Kazakov
0 siblings, 0 replies; 21+ 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 6% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
@ 2008-08-07 2:52 5% ` Randy Brukardt
2008-08-07 8:27 5% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
0 siblings, 1 reply; 21+ 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 5%]
* Re: Ada.Calendar.Time_Zones
@ 2008-08-05 9:10 6% ` Dmitry A. Kazakov
2008-08-07 2:52 5% ` Ada.Calendar.Time_Zones Randy Brukardt
0 siblings, 1 reply; 21+ 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 6%]
* Re: Ada.Calendar.Time_Zones
@ 2008-08-04 14:57 5% ` Dmitry A. Kazakov
0 siblings, 0 replies; 21+ 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 5%]
* Re: Getting current date and time
2007-07-24 8:53 0% ` Maciej Sobczak
2007-07-24 9:41 0% ` Georg Bauhaus
2007-07-24 15:24 4% ` Adam Beneschan
@ 2007-07-28 8:20 0% ` Wilhelm Spickermann
2 siblings, 0 replies; 21+ results
From: Wilhelm Spickermann @ 2007-07-28 8:20 UTC (permalink / raw)
Maciej Sobczak wrote:
>> In Ada 2005, this is handled by the Differences procedure in
>> Ada.Calendar.Arithmetic (9.6.1). You can use
>> Ada.Calendar.Time_Of to create the Time value for January 1,
>> 1970, and then use that as a parameter to Differences.
>
> The problem is that I need just a number of seconds (this is
> for interfacing with other software which uses that Unix-like
> time descriptions), so I cannot use the value which is broken
> down into several components.
>
Then the situation contains even more problems. Every Unix time_t
value has two different meanings depending on the currently(!)
used configuration of the machine. If the local time
configuration (/etc/localtime) is taken from one of the "real"
TZ-Files, then a time_t value of 946684900 decribes the time
"1-jan-2000 00:01:18 UTC". But if the system is configured to
use "posix" TZ-Files, then the same timestamp describes
"1-jan-2000 00:01:40 UTC".
So if you want to produce unix compatible time stamps, you will
have to know the configuration of the destination machine at the
time when the time_t value will be processed.
If you want to interpret time stamps, you need to know the
configuration of the creating machine at the time this time
stamp was made.
If the configuration is one of the "posix" ones, then it's
impossible to create time stamps representing times during
positive leap seconds. Conversely its possible to create time
stamps for times during negative leap seconds leaving us with
time stamps corresponding to no point in real time. Good thing,
that there were no negative leap seconds yet...
If the configuration is one of the "real" ones, then you cannot
compute date strings for time_t values in the far future (more
than about half a year), as the result depends on decisions not
made yet (leap second insertion).
Yet another problem: For historical data the TZ-Files cannot be
taken for real without checking. As TZ-Files fail to have any
representation for "we don't know" or "well, it depends on ...",
many known problems had to be ignored when creating the
TZ-Files. The comments in the source files of the ZIC (Zone
Information Compiler; ZIC produces TZ-Files) should be consulted
if necessary.
Wilhelm Spickermann
^ permalink raw reply [relevance 0%]
* Re: Getting current date and time
2007-07-24 15:24 4% ` Adam Beneschan
@ 2007-07-25 7:26 0% ` Maciej Sobczak
0 siblings, 0 replies; 21+ results
From: Maciej Sobczak @ 2007-07-25 7:26 UTC (permalink / raw)
On 24 Lip, 17:24, Adam Beneschan <a...@irvine.com> wrote:
> > The problem is that I need just a number of seconds (this is for
> > interfacing with other software which uses that Unix-like time
> > descriptions), so I cannot use the value which is broken down into
> > several components.
>
> Why not? Differences returns the result in "days" and "seconds", and
> you should be able to convert the "days" to seconds by multiplying it
> by a value that I just recently helped my 9-year-old figure out, and
> then adding the result to the second value, and then maybe adding the
> leap seconds (see below).
Right. I didn't notice that it's just two components, not more
(without years, months and days).
> We could
> conceivably propose a new addition to Ada.Calendar.Arithmetic:
>
> function
> Return_Current_Time_However_The_Other_Software_Maciej_Is_Using_Does_It;
>
> but I sort of doubt that a proposal like that would be accepted.
On my system Ada.Calendar.Time_Of and Ada.Calendar.Formatting.Time_Of
behave *differenty* with the same arguments, so with such a mess
already in the library no additional proposal could hurt...
Thank you for pointing me in the right direction, I was able now to
get the expected values by using Ada.Calendar.Formatting.Time_Of.
--
Maciej Sobczak
http://www.msobczak.com/
^ permalink raw reply [relevance 0%]
* Re: Getting current date and time
2007-07-24 8:53 0% ` Maciej Sobczak
2007-07-24 9:41 0% ` Georg Bauhaus
@ 2007-07-24 15:24 4% ` Adam Beneschan
2007-07-25 7:26 0% ` Maciej Sobczak
2007-07-28 8:20 0% ` Wilhelm Spickermann
2 siblings, 1 reply; 21+ results
From: Adam Beneschan @ 2007-07-24 15:24 UTC (permalink / raw)
On Jul 24, 1:53 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 23 Lip, 23:43, Adam Beneschan <a...@irvine.com> wrote:
>
> > In Ada 2005, this is handled by the Differences procedure in
> > Ada.Calendar.Arithmetic (9.6.1). You can use Ada.Calendar.Time_Of to
> > create the Time value for January 1, 1970, and then use that as a
> > parameter to Differences.
>
> The problem is that I need just a number of seconds (this is for
> interfacing with other software which uses that Unix-like time
> descriptions), so I cannot use the value which is broken down into
> several components.
Why not? Differences returns the result in "days" and "seconds", and
you should be able to convert the "days" to seconds by multiplying it
by a value that I just recently helped my 9-year-old figure out, and
then adding the result to the second value, and then maybe adding the
leap seconds (see below).
> Moreover, the concept of leap seconds does not fit here neither (or
> does it?).
Your previous post said that the purpose was to "interfac[e] with
other software which uses that Unix-like time descriptions". I don't
think we can answer anything else without knowing just what that other
software does. If the other software uses seconds since January 1,
1970 (regardless of what OS you're on), then you should use the method
I described, and you should either use or not use the leap seconds
depending on whether the other software does or doesn't. If the other
software uses the Unix time function on Unix but some other system
service on other OS's, you should probably just do whatever the other
software does. This one really isn't an Ada problem. We could
conceivably propose a new addition to Ada.Calendar.Arithmetic:
function
Return_Current_Time_However_The_Other_Software_Maciej_Is_Using_Does_It;
but I sort of doubt that a proposal like that would be accepted.
-- Adam
^ permalink raw reply [relevance 4%]
* Re: Getting current date and time
2007-07-24 8:53 0% ` Maciej Sobczak
@ 2007-07-24 9:41 0% ` Georg Bauhaus
2007-07-24 15:24 4% ` Adam Beneschan
2007-07-28 8:20 0% ` Wilhelm Spickermann
2 siblings, 0 replies; 21+ results
From: Georg Bauhaus @ 2007-07-24 9:41 UTC (permalink / raw)
On Tue, 2007-07-24 at 01:53 -0700, Maciej Sobczak wrote:
> On 23 Lip, 23:43, Adam Beneschan <a...@irvine.com> wrote:
>
> > In Ada 2005, this is handled by the Differences procedure in
> > Ada.Calendar.Arithmetic (9.6.1). You can use Ada.Calendar.Time_Of to
> > create the Time value for January 1, 1970, and then use that as a
> > parameter to Differences.
>
> The problem is that I need just a number of seconds (this is for
> interfacing with other software which uses that Unix-like time
> descriptions), so I cannot use the value which is broken down into
> several components.
> Moreover, the concept of leap seconds does not fit here neither (or
> does it?).
If recomputing the seconds doesn't seem adequate,
and you want Unix epoch seconds, why not call the
system function that provides Unix epoch seconds?
^ permalink raw reply [relevance 0%]
* Re: Getting current date and time
2007-07-23 21:43 6% ` Adam Beneschan
@ 2007-07-24 8:53 0% ` Maciej Sobczak
2007-07-24 9:41 0% ` Georg Bauhaus
` (2 more replies)
0 siblings, 3 replies; 21+ results
From: Maciej Sobczak @ 2007-07-24 8:53 UTC (permalink / raw)
On 23 Lip, 23:43, Adam Beneschan <a...@irvine.com> wrote:
> In Ada 2005, this is handled by the Differences procedure in
> Ada.Calendar.Arithmetic (9.6.1). You can use Ada.Calendar.Time_Of to
> create the Time value for January 1, 1970, and then use that as a
> parameter to Differences.
The problem is that I need just a number of seconds (this is for
interfacing with other software which uses that Unix-like time
descriptions), so I cannot use the value which is broken down into
several components.
Moreover, the concept of leap seconds does not fit here neither (or
does it?).
Try this on GNU/Linux:
$ date +%s
I need to get the same number at the time the program is executed.
--
Maciej Sobczak
http://www.msobczak.com/
^ permalink raw reply [relevance 0%]
* Re: Getting current date and time
@ 2007-07-23 21:43 6% ` Adam Beneschan
2007-07-24 8:53 0% ` Maciej Sobczak
0 siblings, 1 reply; 21+ results
From: Adam Beneschan @ 2007-07-23 21:43 UTC (permalink / raw)
On Jul 23, 1:08 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 23 Lip, 22:02, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>
> > I've found it now in the Index - it is described in section 9.6, which
> > is not part of the standard library description.
>
> Still, I don't know how to portably get the number of seconds in the
> Unix epoch (for example, now is 1185221230). The built-in Duration
> type is not guaranteed to have the necessary range.
> How to solve it?
In Ada 2005, this is handled by the Differences procedure in
Ada.Calendar.Arithmetic (9.6.1). You can use Ada.Calendar.Time_Of to
create the Time value for January 1, 1970, and then use that as a
parameter to Differences.
-- Adam
^ 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
1 sibling, 0 replies; 21+ 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, 2 replies; 21+ 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%]
Results 1-21 of 21 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
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
2007-07-23 19:57 ` Maciej Sobczak
2007-07-23 20:02 ` Maciej Sobczak
2007-07-23 20:08 ` Maciej Sobczak
2007-07-23 21:43 6% ` Adam Beneschan
2007-07-24 8:53 0% ` Maciej Sobczak
2007-07-24 9:41 0% ` Georg Bauhaus
2007-07-24 15:24 4% ` Adam Beneschan
2007-07-25 7:26 0% ` Maciej Sobczak
2007-07-28 8:20 0% ` Wilhelm Spickermann
2008-08-04 9:31 Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-04 13:56 ` Ada.Calendar.Time_Zones google1
2008-08-04 14:57 5% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-04 22:12 ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-05 9:10 6% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-08-07 2:52 5% ` Ada.Calendar.Time_Zones Randy Brukardt
2008-08-07 8:27 5% ` Ada.Calendar.Time_Zones Dmitry A. Kazakov
2008-12-09 9:48 Inspiration for a better calendar package? Jacob Sparre Andersen
2008-12-09 10:15 6% ` Martin
2008-12-09 11:15 0% ` Dmitry A. Kazakov
2008-12-09 12:23 0% ` Martin
2009-09-13 15:36 Dates and Times in GNAT on Linux Marc A. Criley
2009-09-13 16:17 6% ` Dmitry A. Kazakov
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 5% ` Adam Beneschan
2015-07-13 13:26 5% Time_Zone-aware Day_of_Week ? Natasha Kerensikova
2015-10-31 20:29 A few questions Laurent
2015-11-01 0:25 ` Jeffrey R. Carter
2015-11-03 6:25 6% ` Randy Brukardt
2016-05-13 20:37 ANN: Introducing AdaBase - Thick database bindings for Ada jrmarino
2016-05-13 21:44 ` Per Sandberg
2016-05-13 23:37 ` Randy Brukardt
2016-05-14 6:59 ` gautier_niouzes
2016-05-16 20:06 5% ` Randy Brukardt
2017-11-19 2:19 When to use Bounded_String? Victor Porton
2017-11-23 10:04 ` briot.emmanuel
2017-12-28 11:46 ` Vincent DIEMUNSCH
2017-12-28 12:00 ` Dmitry A. Kazakov
2017-12-28 12:29 ` Mehdi Saada
2017-12-29 0:42 4% ` Randy Brukardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox