Inspiration for a better calendar package?

Inspiration for a better calendar package?

[Jacob Sparre Andersen]

The last issue of RISKS included a link to a Haskell calendar package:

   http://haskell.org/ghc/docs/latest/html/libraries/time/Data-Time-Clock.html

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!"

Re: Inspiration for a better calendar package?

[Martin]

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

Re: Inspiration for a better calendar package?

[Dmitry A. Kazakov]

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

Re: Inspiration for a better calendar package?

[Martin]

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

Re: Inspiration for a better calendar package?

[JDECS]

Dmitry A. Kazakov wrote:

> 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. 
Please pardon the insertion from a mere mechanic in the world of physics and former (shudder) COBOL programmer who has dealt with a $#!+-load of politicians. [I agree, in a certain quantum way, with the above assertion!]
> It was silly for Ada 2005 to define time arithmetic
> in terms of political time. 
No, not silly, necessity, although not well compartmentalized.
> Especially because there  simply is no way to
> define such arithmetic. Since political time increment "+" is not a
> function of its arguments!
ROFLMAO! Absolutely! Politicians have neither understanding of, nor its consequence, respect for, human time.
(Now, when you get into the aspect of time quanta, there is a *lot* of leverage in the space between!)

Re: Inspiration for a better calendar package?

[Dmitry A. Kazakov]

On Tue, 09 Dec 2008 09:16:19 -0600, JDECS wrote:

> Dmitry A. Kazakov wrote:
> 
>> It was silly for Ada 2005 to define time arithmetic
>> in terms of political time. 

> No, not silly, necessity, although not well compartmentalized.

Silly because they could easily define arithmetic on UTC, providing
conversions to the political time. This could be made in an *unambiguous*
way. Instead of that they defined arithmetic on political time. That just
cannot work, mathematically cannot.

I don't know their motivations. After all, I know no processor+main board
combination which had "political clock" hardware. Maybe some BIOS clock?
But BIOS clock would be unusable anyway...

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

Re: Inspiration for a better calendar package?

[JDECS]

Dmitry A. Kazakov wrote:

> On Tue, 09 Dec 2008 09:16:19 -0600, JDECS wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>> It was silly for Ada 2005 to define time arithmetic
>>> in terms of political time.
> 
>> No, not silly, necessity, although not well compartmentalized.
> 
> Silly because they could easily define arithmetic on UTC, providing
> conversions to the political time. This could be made in an *unambiguous*
> way. Instead of that they defined arithmetic on political time. That just
> cannot work, mathematically cannot.
Essentially agreed, as in the original. Please forgive a certain tongue-in-cheek. I have never had any problem with UTC or even absolute Cesium raw data, but the % of us who understand that what time it is is downtown Chicago, USA is neither relevant nor interesting is vanishingly small.
> 
> I don't know their motivations. After all, I know no processor+main board
> combination which had "political clock" hardware. Maybe some BIOS clock?
> But BIOS clock would be unusable anyway...
> 
Meh, my personal BIOS clock is well used.

Best regards,
=DSM=

Re: Inspiration for a better calendar package?

[Wilhelm Spickermann]

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. 

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".

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".

Wilhelm
(wsp at-character spickermann-d.de)

PS: I've done this in Ada and it's working but it's yet
unpublished as I wanted to add a "clock source" to the time
stamps to handle synchronization problems -- but the years went
by...

PPS: wsp at-character spickermann-d.de for anyone interested
in the doc and source (GMGPL). 
(I'm just now moving to a different town - patience
required :-) )

Re: Inspiration for a better calendar package?

[Dmitry A. Kazakov]

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

Re: Inspiration for a better calendar package?

[m.collado]

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

Re: Inspiration for a better calendar package?

[Dmitry A. Kazakov]

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

Re: Inspiration for a better calendar package?

[Wilhelm Spickermann]

Dmitry A. Kazakov wrote:

>> 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?

Well, I can add 900_000_000 seconds to "now" in the first kind of
time I mentioned. Then we will have a clearly specified point in
time resulting, which we could very well use, to start some
process. But we cannot convert it to UTC, as we do not know all
the leap second rules of the future.

On the other hand, we can make an appointment for the
17-aug-2023, 10:00 UTC and this is also a somehow clearly
specified point in time, as we would be able to meet at that
time. But no one is able to convert this specification to
a "real time" now. (That's why I refuse to call it UTC.)

The resolution of "one nominial minute" (_not_ a physical unit)
for wall clock time was chosen, because it's the finest usable
resultion. We can tell that we have 4 nominal minutes between
31-dec-2044 23:59:58 and 01-jan-2045 00:00:02. But we cannot
express this difference in seconds (or in the physical unit "one
minute"). We will hopefully be able to do that in summer 2044 or
perhaps earlier, when the leap seconds are eliminated.

Wilhelm

Re: Inspiration for a better calendar package?

[Dmitry A. Kazakov]

On Mon, 15 Dec 2008 13:59:02 +0100, Wilhelm Spickermann wrote:

> On the other hand, we can make an appointment for the
> 17-aug-2023, 10:00 UTC and this is also a somehow clearly
> specified point in time, as we would be able to meet at that
> time.

No we cannot. 17-aug-2023, 10:00 UTC has no meaning. We don't know if this
date will ever exist.

> But no one is able to convert this specification to
> a "real time" now. (That's why I refuse to call it UTC.)

This specification does not specify time. It is a text pattern which may
match or not some time point(s) in the future. It exactly same as "when
leaves will turn red."

> The resolution of "one nominial minute" (_not_ a physical unit)
> for wall clock time was chosen, because it's the finest usable
> resultion. We can tell that we have 4 nominal minutes between
> 31-dec-2044 23:59:58 and 01-jan-2045 00:00:02. But we cannot
> express this difference in seconds (or in the physical unit "one
> minute"). We will hopefully be able to do that in summer 2044 or
> perhaps earlier, when the leap seconds are eliminated.

Minute is a physical unit. Political minute is not. We just do not need the
latter, because it does not satisfy some fundamental requirements of a
physical unit, like anisotropy in 4D space. Why bother with it then?

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

Re: Inspiration for a better calendar package?

[sjw]

On Dec 15, 1:46 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 15 Dec 2008 13:59:02 +0100, Wilhelm Spickermann wrote:
> > On the other hand, we can make an appointment for the
> > 17-aug-2023, 10:00 UTC and this is also a somehow clearly
> > specified point in time, as we would be able to meet at that
> > time.
>
> No we cannot. 17-aug-2023, 10:00 UTC has no meaning. We don't know if this
> date will ever exist.

Because the world might have come to an end, maybe? I think we should
restrict ourselves to reasonable possibilities!

Re: Inspiration for a better calendar package?

[Dmitry A. Kazakov]

On Mon, 15 Dec 2008 16:47:56 -0800 (PST), sjw wrote:

> On Dec 15, 1:46�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Mon, 15 Dec 2008 13:59:02 +0100, Wilhelm Spickermann wrote:
>>> On the other hand, we can make an appointment for the
>>> 17-aug-2023, 10:00 UTC and this is also a somehow clearly
>>> specified point in time, as we would be able to meet at that
>>> time.
>>
>> No we cannot. 17-aug-2023, 10:00 UTC has no meaning. We don't know if this
>> date will ever exist.
> 
> Because the world might have come to an end, maybe? I think we should
> restrict ourselves to reasonable possibilities!

If you say that you can predict political regulations on this matter, then
that automatically removes the issue.

Remember that the point was, that 17-aug-2023 refers to an unknown UTC
time, because we cannot know future regulations. Now, either we know them,
or not. If we know them, then 17-aug-2023 for any given point on the Earth
refers to an UTC time. If we don't then 17-aug-2023 is meaningless at the
locations of unknown regulations.

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

Re: Inspiration for a better calendar package?

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> Remember that the point was, that 17-aug-2023 refers to an unknown UTC
> time, because we cannot know future regulations. Now, either we know them,
> or not. If we know them, then 17-aug-2023 for any given point on the Earth
> refers to an UTC time. If we don't then 17-aug-2023 is meaningless at the
> locations of unknown regulations.

Can you perhaps declare your own time reference?
If your times need to reflect well defined earthly
physical periods exactly, why not refer to some
unambigous physical entity?

Re: Inspiration for a better calendar package?

[Wilhelm Spickermann]

Dmitry A. Kazakov wrote:

> On Mon, 15 Dec 2008 13:59:02 +0100, Wilhelm Spickermann wrote:
> 
>> On the other hand, we can make an appointment for the
>> 17-aug-2023, 10:00 UTC and this is also a somehow clearly
>> specified point in time, as we would be able to meet at that
>> time.
> 
> No we cannot. 17-aug-2023, 10:00 UTC has no meaning. We don't
> know if this date will ever exist.

May be we do not exist then, may be the gregorian calendar will
not be in use then, but I don't see any reason for this date of
a (proleptic) gregorian calendar to be impossible.

> 
>> But no one is able to convert this specification to
>> a "real time" now. (That's why I refuse to call it UTC.)
> 
> This specification does not specify time. It is a text pattern
> which may match or not some time point(s) in the future. It
> exactly same as "when leaves will turn red."

Yes, it does not specify a point in time -- but it will do.

> 
>> The resolution of "one nominial minute" (_not_ a physical
>> unit) for wall clock time was chosen, because it's the finest
>> usable resultion. We can tell that we have 4 nominal minutes
>> between 31-dec-2044 23:59:58 and 01-jan-2045 00:00:02. But we
>> cannot express this difference in seconds (or in the physical
>> unit "one minute"). We will hopefully be able to do that in
>> summer 2044 or perhaps earlier, when the leap seconds are
>> eliminated.
> 
> Minute is a physical unit. Political minute is not. We just do
> not need the latter, because it does not satisfy some
> fundamental requirements of a physical unit, like anisotropy in
> 4D space. Why bother with it then?
> 

We need it, because someone in some plant has to specify a report
to be printed on the 1-jul-2009 00:00 UTC. You cannot tell him,
that he should wait a month from now until the IERS has
published it's decision about leap second insertion at the end
of next June. 
So we have to accept this kind of specification before we can
tell to which time it is referring. If we don't define a type
for that kind of data, the programs will store strings instead
and no one will check input upon typing for nonsense
like "31-feb-2009".

I do see your point, that's why I propose using two time types
with a well defined relation. This kind of time description has
some really bad properties and I strongly support giving up the
introduction of leap seconds, to be able to give up this second
time type.

Surely there are applications (like an unmanned space ship) which
do not need "wall time" and they will simply not use the
package. They will probably also omit the packages for time zone
handling and leap second handling.

Wilhelm

Re: Inspiration for a better calendar package?

[Dmitry A. Kazakov]

On Tue, 16 Dec 2008 06:50:40 +0100, Wilhelm Spickermann wrote:

> Dmitry A. Kazakov wrote:
> 
>> This specification does not specify time. It is a text pattern
>> which may match or not some time point(s) in the future. It
>> exactly same as "when leaves will turn red."
> 
> Yes, it does not specify a point in time -- but it will do.

Where you know that from?

> We need it, because someone in some plant has to specify a report
> to be printed on the 1-jul-2009 00:00 UTC. You cannot tell him,
> that he should wait a month from now until the IERS has
> published it's decision about leap second insertion at the end
> of next June. 

No we don't. You cannot show a code that neither:

1. Waits a fixed amount of time (delay until)

2. Periodically polls actual time (delay delta, look at the time).

There is simply no other way to determine if the report has to be printed.
In either case you don't need another "time."

It can be shown even simpler, printing is an action in real time. You
cannot present any physical action that happens in political time.

Political fictions are incomputable. (:-))

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

Re: Inspiration for a better calendar package?

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> It can be shown even simpler, printing is an action in real time. You
> cannot present any physical action that happens in political time.
> 
> Political fictions are incomputable. (:-))

Political time is decidable, though, because political
decisions are not restricted by adherence to the limits
of Turing machines and their relatives.  Insofar as what matters
in business when deciding which time it is, are "political survival",
reasonable profit versus insurance cost or loss of reputation,
customers who might sue you, ... the parties only need to agree
on definitions and procedures regarding the meaning of time
stamps.

Let the lawers find the rules.  Hold the machines during
the leap second, if necessary on an as-if basis.

(Example: taxation changes on 200Y-MM-DD.  Let this day
have a leap second.  Let a financial transaction take
place during that leap second.  Will they have to pay
the new taxes?  Solution: Avoid the question. Just
hold it until you can be sure the new time has been
enacted.  Restart your system, or switch to the
backup system that was prepared for the new time.)

Re: Inspiration for a better calendar package?

[Wilhelm Spickermann]

Dmitry A. Kazakov wrote:

> On Tue, 16 Dec 2008 06:50:40 +0100, Wilhelm Spickermann wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>> This specification does not specify time. It is a text
>>> pattern which may match or not some time point(s) in the
>>> future. It exactly same as "when leaves will turn red."
>> 
>> Yes, it does not specify a point in time -- but it will do.
> 
> Where you know that from?

I do not know it, but the program will know that too and give an
appropriate error message. (see below)

> 
>> We need it, because someone in some plant has to specify a
>> report to be printed on the 1-jul-2009 00:00 UTC. You cannot
>> tell him, that he should wait a month from now until the IERS
>> has published it's decision about leap second insertion at the
>> end of next June.
> 
> No we don't. You cannot show a code that neither:
> 
> 1. Waits a fixed amount of time (delay until)
> 
> 2. Periodically polls actual time (delay delta, look at the
> time).
> 
> There is simply no other way to determine if the report has to
> be printed. In either case you don't need another "time."
> 
> It can be shown even simpler, printing is an action in real
> time. You cannot present any physical action that happens in
> political time.
> 
> Political fictions are incomputable. (:-))
> 

Hmmm, now some secretary is trying to type in the dates of her
next summer holiday and the computer tells her "Cannot do it,
it's just a political fiction"? :-)

The program would first wait for about 3 months and then try to
convert the "wall time" into a "time". If it is still impossible
then, because the leap second second tables weren't updated, the
program should give a warning and perhaps rescedule the check. 

Stricly spoken, we depend on some things, which may change. But
if the earth starts rotating in a way that we need leap seconds
every few minutes, then the program will still give appropriate
warnings or errors (and probably no one will read them, because
we have bigger problems to solve).

I think, there are many computable things within "wall time",
like easter dates or the number of days between the third
Thusdays in January and February in 2010 or the existence of
29-feb-2014. It is however typical for it, that some
computations need additional information, which is not available
now. It's the main purpose of this type, to check everything
checkable and to refuse an answer, if there is none at the time
of the call.

Wilhelm

PS: Sorry for answering late. I'm in the process of moving to
another town and already swapping...

Re: Inspiration for a better calendar package?

[Dmitry A. Kazakov]

On Wed, 17 Dec 2008 07:16:48 +0100, Wilhelm Spickermann wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Tue, 16 Dec 2008 06:50:40 +0100, Wilhelm Spickermann wrote:
>> 
>>> We need it, because someone in some plant has to specify a
>>> report to be printed on the 1-jul-2009 00:00 UTC. You cannot
>>> tell him, that he should wait a month from now until the IERS
>>> has published it's decision about leap second insertion at the
>>> end of next June.
>> 
>> No we don't. You cannot show a code that neither:
>> 
>> 1. Waits a fixed amount of time (delay until)
>> 
>> 2. Periodically polls actual time (delay delta, look at the
>> time).
>> 
>> There is simply no other way to determine if the report has to
>> be printed. In either case you don't need another "time."
>> 
>> It can be shown even simpler, printing is an action in real
>> time. You cannot present any physical action that happens in
>> political time.
>> 
>> Political fictions are incomputable. (:-))
> 
> Hmmm, now some secretary is trying to type in the dates of her
> next summer holiday and the computer tells her "Cannot do it,
> it's just a political fiction"? :-)
> 
> The program would first wait for about 3 months and then try to
> convert the "wall time" into a "time". If it is still impossible
> then, because the leap second second tables weren't updated, the
> program should give a warning and perhaps rescedule the check. 

You don't need wall time for this. That is the case no.2, I mentioned
above, programmed as follows:

delay 60.0 * 60.0 * 24.0 * 30.0 * 3; -- three physical months
if Month (Clock) = ... and Day (Clock) = ... then
   -- do things
else
   -- give warning
end if;

Where is any problem? Except that the algorithm is not good. It should be
(still the case 2):

   delay 60.0 * 60.0 * 24.0 * 25.0 * 3; -- come close enough to judge
   delay until Time_Of (Year =>..., Month =>..., Day =>...);
   -- do things
exception
   when Time_Error =>  -- watch your fingers lady!

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

Re: Inspiration for a better calendar package?

[Wilhelm Spickermann]

Dmitry A. Kazakov wrote:

> Where is any problem? Except that the algorithm is not good. It
> should be (still the case 2):
> 
> delay 60.0 * 60.0 * 24.0 * 25.0 * 3; -- come close enough to
>                                      --  judge 
> delay until Time_Of (Year =>..., Month =>..., Day =>...); 
> -- do things
> exception
>   when Time_Error =>  -- watch your fingers lady!

One problem is, that the error message may come 75 days after
typing here. 

Trying to solve this problem lead me to "wall time". If we do all
the checks possible early and also take into account the given
time zone and then store the result in a time zone independent
way into some opaque type, which can later be transformed
further -- then this opaque type is just the proposed "wall
time".

Another problem is, that the result type and also the operation
of Time_Of may depend on the Operating System configuration. In
most OS I know, there is no possibility to give an error message
about missing leap second information. The case of a missing
leap second information is just handled as the case of no leap
second. And adding leap seconds or for instance changing a Unix
from "posix" to "right" localtime will bring the times to jump
around even if everything was given in UTC.

Wilhelm

Re: Inspiration for a better calendar package?

[Dmitry A. Kazakov]

On Thu, 18 Dec 2008 22:48:52 +0100, Wilhelm Spickermann wrote:

> Dmitry A. Kazakov wrote:
> 
>> Where is any problem? Except that the algorithm is not good. It
>> should be (still the case 2):
>> 
>> delay 60.0 * 60.0 * 24.0 * 25.0 * 3; -- come close enough to judge 
>> delay until Time_Of (Year =>..., Month =>..., Day =>...); 
>> -- do things
>> exception
>>   when Time_Error => �-- watch your fingers lady!
> 
> One problem is, that the error message may come 75 days after
> typing here. 

Right. That is the problem of political time.

> Trying to solve this problem lead me to "wall time". If we do all
> the checks possible early and also take into account the given
> time zone and then store the result in a time zone independent
> way into some opaque type, which can later be transformed
> further -- then this opaque type is just the proposed "wall
> time".

No you cannot detect these errors early. I don't mean the errors like June,
31  etc. These you can detect using Time_Of. But the errors caused by
future regulations are fundamentally impossible to detect before
regulations to happen.

Ultimately you need to translate a political time specification into real
time. What you propose is another way to specify political time (as a data
type). That does not change anything. This new specification is as
impossible to translate into real time as any other.

> Another problem is, that the result type and also the operation
> of Time_Of may depend on the Operating System configuration. In
> most OS I know, there is no possibility to give an error message
> about missing leap second information. The case of a missing
> leap second information is just handled as the case of no leap
> second. And adding leap seconds or for instance changing a Unix
> from "posix" to "right" localtime will bring the times to jump
> around even if everything was given in UTC.

But this is a compiler vendor's problem. If OS has some holes/bugs in its
time services, then there is little we can do about it. Ada cannot define
its own time source. Time is incomputable.

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

Re: Inspiration for a better calendar package?

[Wilhelm Spickermann]

Dennis Lee Bieber wrote:

>> The resolution of "one nominial minute" (_not_ a physical
>> unit) for wall clock time was chosen, because it's the finest
>> usable resultion. We can tell that we have 4 nominal minutes
>> between 31-dec-2044 23:59:58 and 01-jan-2045 00:00:02. But we
>> cannot express this difference in seconds (or in the physical
>> unit "one minute"). We will hopefully be able to do that in
>> summer 2044 or perhaps earlier, when the leap seconds are
>> eliminated.
>>
> Pardon? 23:59:58 incrementing to 00:00:02 is a change of four
> SECONDS, not minutes.

OOps, sorry. I should have used 31-dec-2044 23:58 and 01-jan-2045
00:02.

But it is not four seconds, it is three, four or five seconds,
depending on yet unknown leap second decisions.

Wilhelm