From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ee78aab9bfd2fe2a X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news-1.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Wilhelm Spickermann Newsgroups: comp.lang.ada Subject: Re: Inspiration for a better calendar package? Date: Tue, 16 Dec 2008 06:50:40 +0100 Message-ID: <6qottgFdsslcU1@mid.individual.net> References: <873agxd6i1.fsf@nbi.dk> <12gqldae49yoe$.1sf2zlz1fthvh.dlg@40tude.net> <6qmg8dFd8kd2U1@mid.individual.net> <1jv16tgrmhor4$.c3a8ugjxu6ed$.dlg@40tude.net> <6qn2kmFdflp2U1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: individual.net 3NISpjzq95vCfKwnrfia4QvsM0tRHaWerwqohgBsJkOMt8w4FZ Cancel-Lock: sha1:K9IsC8RxGMO7BhWYQnJqXjJb4qg= Xref: g2news1.google.com comp.lang.ada:3003 Date: 2008-12-16T06:50:40+01:00 List-Id: 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