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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,92471489ebbc99c6 X-Google-Attributes: gid103376,public From: smize@news.imagin.net (Samuel Mize) Subject: Re: Y2K Issues Date: 1998/10/29 Message-ID: <71a64p$14o4$1@prime.imagin.net>#1/1 X-Deja-AN: 406361310 References: <362B53A3.64E266AB@res.raytheon.com> <717kpq$7cv$1@platane.wanadoo.fr> Organization: ImagiNet Communications Ltd, Arlington, Texas Reply-To: smize@imagin.net (Samuel Mize) Newsgroups: comp.lang.ada Date: 1998-10-29T00:00:00+00:00 List-Id: In article , Dale Stanbrough wrote: >Don't we just need to support dates in the same way we support time, >i.e. have a universal date (like GMT), and then supply localisation >routines which allow different locations to convert from/to local >calendars... > > package Calendar; > package Calendar.Monotonic; > package Calendar.Monotonic.Gregorian > package Calendar.Monotonic.Julian; Sounds reasonable. Package Calendar won't handle Genealogy, History, Astronomy -- what's WRONG with its design? NOTHING! It was intended to be a representation of "now" and nearby times in embedded systems. We don't need a compiler-based standard for time, we just need some commonly-distributed packages that implement useful versions of time, depending on what you're doing. Are you really planning to write a delay statement that will show up in a geological time frame? Best, Sam Mize -- Samuel Mize -- smize@imagin.net (home email) -- Team Ada Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam