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.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: ff6c8,37e6dbf5e31f6da0 X-Google-Attributes: gidff6c8,public X-Google-Thread: 1108a1,37e6dbf5e31f6da0 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,37e6dbf5e31f6da0 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,37e6dbf5e31f6da0 X-Google-Attributes: gidf43e6,public X-Google-Thread: 10db24,37e6dbf5e31f6da0 X-Google-Attributes: gid10db24,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Software Engineering News Brief Date: 1996/11/17 Message-ID: #1/1 X-Deja-AN: 197021941 references: <55nqea$32a@news2.delphi.com> <3280BAFA.1B2F@email.mot.com> <563tle$cu7$1@shade.twinsun.com> <56lvss$r82@mulga.cs.mu.OZ.AU> organization: New York University newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-11-17T00:00:00+00:00 List-Id: Fergus said "I don't think it is a highly specialized requirement. I think the requirement for a generic date type the works over a large range of dates is quite common. Many programs let users enter dates, and putting strict requirements on the dates entered is not unlike assuming that no-one will ever want to enter a line with more than 80 characters." Almost all programs that let users enter dates will want to consider a date from the 25th century as illegal, just as illegal as the 30th of February. It is indeed a specialized requirement to need dates very far from the present. I certainly have never written such a program, and I have written MANY programs that handle dates! "Gregorian dates aren't tricky, the change-over from other systems is tricky. That's why Paul Eggert suggested supporting Gregorian dates only, even for dates before the Gregorian system was used." Well I know that's what he said, but I thought it must be a slip, because it is so obviously an undesirable suggestion. To accept dates before the 18th century without comment or error, and then misinterpret them seems highly error prone. Any program that wants to deal with dates before the switch over must surely worry for itself about how to deal with this situation. If I have a program that tells me the day of the week for any date, and I use it to see what day of the week the Magna Carta was signed, I either want the right answer, or an error, I certainly do NOT want to get an incorrect answer corresponding to what the day would have been had the Pope switched over the dates much earlier! Also, dates that go outside the Ada range are tricky for another reason, since they need geopolitical normalization in any case. The question of whether a year is a leap year or not is not a scientific or astronomical one, it is a political one, since it depends on the laws of the country involved. All countries agree for the Ada range of dates, but when you wander outside this range, countries will disagree unless they change their laws. Again, deciding whether you want the date according to the current law, or according to some other scheme, is surely something a program must decide for itself. Dates are not as simple as you think! In particular, I am pretty sure that when people talk about Gregorian dates, they do not mean what they say (i.e. they are not talking about dates according to the scheme that Pope Gregory decreed). That again is because the system of leap years has changed since then, so that in some countries the laws of the country do not correspond to Gregorian dates. For example, I know the rule that every 100 years is not a leap year, except that every 400 years is a leap year, but I do not know if this corresponds to the current legislation of the US. There are also higher order corrections proposed, so if you want to do a program that converts from Star Dates to standard dates, you will have to find out the details of Federation legislation regarding dates first.