FAQ faults
in [Shell]
|
Prev: Bulk moving of files
Next: B.C. and A.L.
From: bsh on 29 Mar 2010 19:48 Dr. J.R. Stockton <reply1...(a)merlyn.demon.co.uk> wrote: > "Brian Hiles" <brian_hi...(a)rocketmail.com> posted: > > Dr. J.R. Stockton <reply1...(a)merlyn.demon.co.uk> wrote: > > > ... > > http://kornshell.com/doc/faq.html > That is, currently, a dismal document : no date, no named author, and > apparently only one shell. Dismal? Yes, it has a long way to go, but it _is_ authored by the progenitor of ksh(1), David G. Korn, pertainent to the latest, newest, and most advanced of shells of this lineage. > > > 6d. Determining leap year > > > ... > > Proposals, to be sure, but a code library _must_ make it clear > > ... > > as to which standard is used to make the calculation. > There is only two true standards for the secular Gregorian Calendar : > one is the Papal Bull of 1582 (a.k.a. 1581) issued by Gregory XIII > (Easter is defined in the Six Canons and the Explicatio of Clavius). A > modified calendar could only be Gregorian if it were issued by a later > Pope Gregory, or some other authority of that name. The other is the > British Calendar Act of 1751 for Leap Year, and its Annex for Easter. Interesting, but how is this pertainent to the statement? > Our full secular current calendar is also defined in ISO 8601. ISO 8601:2004 discusses a standardized format to express dates, times, and time periods in the Gregorian calendar. How does it "define a secular calendar"? > Proposals are not standards. Those will not be implemented in our time; > and, if they were, the result would not be Gregorian. But I said as much, only adding that formal standards should make explicit the context! > > > In the Julain calendar which was used before in Europe, only the > > > years divisible by 4 where leap years. > > Sort of. The Julian Calendar, ... > > ... had further difficulties at its inception > > because of an error of implementation essentially making the first > > few leap years every three years, not four. > > ... > Partially true. The Julian Calendar, used from about BC 45, has a Leap > Year *every* 4 years. The implementation errors did not affect the > calendar of the Emperor Caesar; ... http://en.wikipedia.org/wiki/Julian_calendar#Leap_year_error > ... they merely affected the Roman civil > calendar. And more than half of Europe was unaffected; essentially only > France, most of Spain, Italy, Greece, and the coast in between in 44 BC, > with Switzerland to the Balkans being added by 14 AD. But of course... but beside the point. > > Indeed, if we are talking about day-day demarcations, which is what > > the JDN is all about, discussion has to made of the 22+ leap-seconds > > that have been inserted into the calendar since 1970, which could > > (or have?) appear on the ISO-standard 61th second (!) of 11:59pm, > > theoretically erroneously shifting the determination of a given > > day. > Only if the day is determined as if by a SI clock. The traditional > method is to rely on the alternating light and dark. Yes, yes, but my intention was to give a simple example of the problematic nature of sweeping calendrical assertions; I stand by my assertion in explicit context of the previous paragraph that calendrical calculation is profoundly nuanced. > Before worrying > about the occasional +- 1 second, one should consider the Equation of > Time, which affected the length of the civil day until good clocks were > in use. Sidereal time issues are yet _another_ facet of the problem of time measurement and calendrical calculation! Is the Astronomical Ratio pertainent to the Equation of Time? The Antikythera Device! http://en.wikipedia.org/wiki/Antikythera_mechanism > > ... which is _always_ > >different) is dependant on the relative time that the northern > >and southern hemispheres spend in that year's winter! (*) No > >wonder why the JDN was instigated! > No; the length of a civil day is 86400 +- 1 SI seconds, +- 0.5 or 1 > hour. > But that has nothing to do with the calendar, which is a means of > labelling a sequence of days independently of how their bounds are > determined. Why did you think I necessarily meant "civil day"? You cannot think, I hope, that I don't know the difference.... > > You are correct that this is incredibly naive of the cal(1) > > software tool. > No; I'm not commenting on the tool (and so cannot be right or wrong > about it), but on what that FAQ actually says. I was not intending any disrespect.... > > 25 countries and provinces have adopted the > > Gregorian calendar on 18 different dates, ranging from the > > year 1582 to as late as 1949. > That cannot be correct. It is correct. And completely beside the point of the modern calendar, except to support my thesis (calendars are complex!) and in regard to correct proleptic calendrical calculation, which cal(1) aspires to do. Upon an informal investigation of an aforementioned matter elsewhere in this thread, I think both ncal(1) and NetBSD cal, are no better than cal(1) for the same moot assumptions that are used. I say again, this is my point: calendrical calculations are pragmatic only if assumptions are explicit, and certain givens are respected, such as no proleptic dates before the Gregorian calendar -- IIRC, affecting cal(1). > ... (to within the limits of the machine's > arithmetic capability) or that their limits are clearly stated within > the code. Yes! > Be aware that, for example, Microsoft got ISO Week Numbering wrong, and > have not corrected the distribution for over half a decade after they > put "bug-fix" code (an appalling implementation) on their Web site; and > Gauss got Easter wrong at first. So it would be unsafe to assume that > anything found on the Web or in libraries is necessarily correct. Hmmm. My Windows Mobile 6.1 smartphone, due to a new-age "off-by-one" daylight-savings-time error, has munged all my appointments -- both future _and_ past! *Grrr!* While we're talking about k/sh, are you aware of the new feature implementing simple calendrical calculation within new printf directive "%T", probably based on the enhanced AST time.h functions? https://mailman.research.att.com/pipermail/ast-developers/2004q3/000083.html https://mailman.research.att.com/pipermail/ast-users/2007q1/001704.html https://mailman.research.att.com/pipermail/ast-developers/2008q4/000417.html https://mailman.research.att.com/pipermail/ast-users/2009q4/002671.html printf "%(%K)T\n" "Sept 23 2009 noon" printf "%(%K)T\n" "Sept 23 2009 noon 90 days" printf "%(%K)T\n" "Sept 23 2009 noon 90 days hence" printf "%(%K)T\n" "Sept 23 2009 noon 90 days ago" No more nonsense using date(1) with pathological TZ values as the usual kludge! =Brian
From: Jonathan de Boyne Pollard on 30 Mar 2010 16:02 > > > Be aware that, for example, Microsoft got ISO Week Numbering wrong, [...] > Interesting. Where?
From: Stephane CHAZELAS on 31 Mar 2010 02:39 2010-03-28, 21:17(+01), Dr J R Stockton: [...] > So it would be unsafe to assume that > anything found on the Web or in libraries is necessarily correct. [...] BTW, since there are quite savvy people on the subject on this thread, could anyone comment on the correctness of http://stchaz.free.fr/wide_strftime.sh (a POSIX shell implementation of some date related utilities that tries to cover negative years as well). I wrote that quite some time ago, I'm not so versed in those calendar issues but had tried to validate it against other implementations at the time (gcal and GNU strftime IIRC). That implementation implies UTC, POSIX LC_TIME, no leap second and a switch from Julian to Gregorian in 1752. -- Stéphane
From: Dr J R Stockton on 31 Mar 2010 15:15 In comp.unix.shell message <7223e8e0-0e09-408e-9dcb-addcab677fd9(a)l18g200 0prm.googlegroups.com>, Mon, 29 Mar 2010 16:48:13, bsh <brian_hiles(a)rocketmail.com> posted: >Dr. J.R. Stockton <reply1...(a)merlyn.demon.co.uk> wrote: >> "Brian Hiles" <brian_hi...(a)rocketmail.com> posted: >> > Dr. J.R. Stockton <reply1...(a)merlyn.demon.co.uk> wrote: >> > > 6d. Determining leap year >> > > ... >> > Proposals, to be sure, but a code library _must_ make it clear >> > ... >> > as to which standard is used to make the calculation. >> There is only two true standards for the secular Gregorian Calendar : >> one is the Papal Bull of 1582 (a.k.a. 1581) issued by Gregory XIII >> (Easter is defined in the Six Canons and the Explicatio of Clavius). A >> modified calendar could only be Gregorian if it were issued by a later >> Pope Gregory, or some other authority of that name. The other is the >> British Calendar Act of 1751 for Leap Year, and its Annex for Easter. > >Interesting, but how is this pertainent to the statement? It pours scorn on the ridiculous apparent assertion that there are multiple non-equivalent standards for our present (Gregorian) Calendar. >> Our full secular current calendar is also defined in ISO 8601. > >ISO 8601:2004 discusses a standardized format to express >dates, times, and time periods in the Gregorian calendar. >How does it "define a secular calendar"? You should read ISO 8601. Section "3.2.1 The Gregorian calendar" defines the Gregorian calendar, omitting consideration of the date of Easter - therefore secular. The definition is exact, apart from a weakness in so far as its definition of the positioning of the calendar along a scale of days is not reproducible (and could easily be improved). The Papal Bull and the Calendar Act define Leap Years; I don't recall any other formal definition of the present months and their lengths, apart from that obtained by tracing Roman legal history. >> Proposals are not standards. Those will not be implemented in our time; >> and, if they were, the result would not be Gregorian. > >But I said as much, only adding that formal standards should >make explicit the context! > >> > > In the Julain calendar which was used before in Europe, only the >> > > years divisible by 4 where leap years. >> > Sort of. The Julian Calendar, ... >> > ... had further difficulties at its inception >> > because of an error of implementation essentially making the first >> > few leap years every three years, not four. >> > ... >> Partially true. The Julian Calendar, used from about BC 45, has a Leap >> Year *every* 4 years. The implementation errors did not affect the >> calendar of the Emperor Caesar; ... > >http://en.wikipedia.org/wiki/Julian_calendar#Leap_year_error Wikipedia is not invariably accurate. But that section, although in the page "Julian calendar", does NOT describe the actual calendar of the erroneous years as being Julian; it rightly makes a clear distinction between "Roman" and "Julian". >> ... they merely affected the Roman civil >> calendar. And more than half of Europe was unaffected; essentially only >> France, most of Spain, Italy, Greece, and the coast in between in 44 BC, >> with Switzerland to the Balkans being added by 14 AD. It refers to the FAQ error of putting "which was used before in Europe", which would commonly be taken as meaning at least the majority of Europe. Better to have put "by Rome", which would naturally encompass the Roman Empire of the time, in and out of Europe. > >But of course... but beside the point. > >> > Indeed, if we are talking about day-day demarcations, which is what >> > the JDN is all about, discussion has to made of the 22+ leap-seconds >> > that have been inserted into the calendar since 1970, which could >> > (or have?) appear on the ISO-standard 61th second (!) of 11:59pm, >> > theoretically erroneously shifting the determination of a given >> > day. >> Only if the day is determined as if by a SI clock. The traditional >> method is to rely on the alternating light and dark. > >Yes, yes, but my intention was to give a simple >example of the problematic nature of sweeping >calendrical assertions; I stand by my assertion >in explicit context of the previous paragraph that >calendrical calculation is profoundly nuanced. That is an incorrect assertion, at least as regards the Gregorian and Julian Calendars, both of which were accurately defined at their inceptions - except where the date of the start of usage is not known with accurate certainty. >> Before worrying >> about the occasional +- 1 second, one should consider the Equation of >> Time, which affected the length of the civil day until good clocks were >> in use. > >Sidereal time issues are yet _another_ facet of the >problem of time measurement and calendrical calculation! Time measurement, yes. Calendar, no. >> > ... which is _always_ >> >different) is dependant on the relative time that the northern >> >and southern hemispheres spend in that year's winter! (*) No >> >wonder why the JDN was instigated! >> No; the length of a civil day is 86400 +- 1 SI seconds, +- 0.5 or 1 >> hour. >> But that has nothing to do with the calendar, which is a means of >> labelling a sequence of days independently of how their bounds are >> determined. > >Why did you think I necessarily meant "civil >day"? You cannot think, I hope, that I don't >know the difference.... The Calendar relates to the Civil Day, either the local one or that (disregarding Summer Time) at Greenwich. Determination of the exact instant of change is another matter entirely. For example, we need have no doubt at all that Gregorian Easter Sunday of the year 1234567 will be on March 22nd. We do not know whether the people, if any, of the time will be using Gregorian dates or celebrating Easter; and we do not know exactly how many SI seconds will have elapsed between the beginning of 1970 UTC and that civil date at any location, but that is another matter. >> > 25 countries and provinces have adopted the >> > Gregorian calendar on 18 different dates, ranging from the >> > year 1582 to as late as 1949. >> That cannot be correct. > >It is correct. And completely beside the point of >the modern calendar, except to support my thesis >(calendars are complex!) and in regard to correct >proleptic calendrical calculation, which cal(1) >aspires to do. Then name your 25, and I will refute you by naming a 26th. I will have (disregarding provinces) about 175 to choose from. Peru alone has 195 provinces. For general-purpose computer systems in countries now using only the Gregorian Calendar for ordinary information technology, only the Gregorian Calendar should be used; getting anything else reliably right has been proven too difficult. Where anything else is required, let them do (and debug) it themselves in their own dominant localities. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05. Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
From: Dr J R Stockton on 1 Apr 2010 18:10
In comp.unix.shell message <slrnhr5rhq.4vm.stephane.chazelas(a)spam.is.inv alid>, Wed, 31 Mar 2010 06:39:54, Stephane CHAZELAS <stephane_chazelas(a)yahoo.fr> posted: >2010-03-28, 21:17(+01), Dr J R Stockton: >[...] >> So it would be unsafe to assume that >> anything found on the Web or in libraries is necessarily correct. >[...] > >BTW, since there are quite savvy people on the subject on this >thread, could anyone comment on the correctness of >http://stchaz.free.fr/wide_strftime.sh (a POSIX shell >implementation of some date related utilities that tries to >cover negative years as well). I wrote that quite some time ago, >I'm not so versed in those calendar issues but had tried to >validate it against other implementations at the time (gcal and >GNU strftime IIRC). That implementation implies UTC, POSIX >LC_TIME, no leap second and a switch from Julian to Gregorian in >1752. For "Great Britain", you should put "Britain and Colonies". "Great Britain" excludes the whole of Ireland. "Julian day number" requires "Julian Calendar" and "GMT" with the date, to be strict. Consider the ISO 8601 treatment of negative years and Year 0, which conflicts with yours. IMHO, a general-purpose date system should number years in the natural manner, -2 -1 0 +1 +2, and provide helper functions to convert between that and BC/AD notation. You could have a utility to convert day-of-week between "C" and "ISO" numbering. Coding is trivial, but the existence of the routines could help the chrono-ignorant. Maybe also for month numbering, 0-base & 1-base. Full ISO 8601 support should be welcome. I'd write 1970/1/1 as 1970/01/01 or 1970-01-01, etc. Word "nor" should be "or", twice. Since other countries, such as .fr, changed calendars at various dates, I think it would be more useful to put the change date as variable. And since Gregorian years are occasionally used in Julian times, and /vice versa/, I think it would be well to be able to set the change to the farthest past or future. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05. Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc. |