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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.182.236.225 with SMTP id ux1mr14169306obc.2.1446385927187;
        Sun, 01 Nov 2015 05:52:07 -0800 (PST)
X-Received: by 10.182.210.134 with SMTP id mu6mr171150obc.20.1446385927151;
 Sun, 01 Nov 2015 05:52:07 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!i2no1406437igv.0!news-out.google.com!fs1ni4820igb.0!nntp.google.com!i2no1406429igv.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sun, 1 Nov 2015 05:52:06 -0800 (PST)
In-Reply-To: <6e188805-0cac-4739-a6dc-234efd392909@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=2001:7e8:d039:4f01:9dac:97d9:1ff6:6a9c;
 posting-account=sDyr7QoAAAA7hiaifqt-gaKY2K7OZ8RQ
NNTP-Posting-Host: 2001:7e8:d039:4f01:9dac:97d9:1ff6:6a9c
References: <f487cd6f-f4f0-437e-9077-0495d17156f3@googlegroups.com>
 <6e188805-0cac-4739-a6dc-234efd392909@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7322394c-9629-45ae-8a29-c04c309ed3d6@googlegroups.com>
Subject: Re: A few questions
From: Laurent <lutgenl@icloud.com>
Injection-Date: Sun, 01 Nov 2015 13:52:07 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:28161
Date: 2015-11-01T05:52:06-08:00
List-Id: <comp.lang.ada>

On Sunday, 1 November 2015 14:42:17 UTC+1, brbar...@gmail.com  wrote:
> You could translate the YYYYMMDD time into a continuous numerical value
> and then use Ada.Real_Time to convert that value to time in seconds from
> some selected starting point.
>=20
> The way astronomers track time is to go over to counting seconds from=20
> Jan. 0, 2013 BCE.  The variable is called Astronomical Julian Date.
> The current value is fairly large, particularly if you want a time=20
> resolution in microseconds.  GPS time is close to Julian Date, but
> uses a starting date closer to the present.
>=20
> Seidelmann, P. K., 2006: Explanatory Supplement to the Astronomical
> Almanac, University Science Books, Sausalito, CA
>=20
> is the definitive reference. =20
>=20
> Savage, N., 2015: Split Second, Comm. ACM, 58, No. 9, 12-14
>=20
> deals with "The issue of whether to add a `leap second' to square
> the clock with the Earth's orbit pits time specialists against IT."
> (quoting from the index to that issue of CACM).
>=20
> To put it simply, Astronomical Julian Date (and relatives) produces=20
> a uniform time record in seconds,  It also makes sure that all dates/time=
s
> are reduced to the same time zone at the Greenwich meridian.  The usual
> IT convention (YYYYMMDD) is non-uniform (for example, Feb. may have 28
> or 29 days - while Jul. always has 31).  It would seem that if your
> application might move to a geographically distributed environment,
> the Julian Date would be sensible.  On the other hand, Julian Date is
> not readily interpretable to humans.
>=20
> Bruce B.

Thanks for the info but I fear that it is more than overkill.=20

It also shows that most "standards" have gotten this status only because th=
ings have been like that before and not because they are the best possible =
solution.=20

So if you have a better solution than the actual one but are not part of a =
large community which supports this, then you can burn it immediately. Only=
 because no one wants to change a thing and prefer to use some crappy solut=
ion over changing something and investing time and effort.

Somehow this world sucks.