Re: Date representations: Y2k revisited
In 4d35e066.9080...@ync.net, on 01/18/2011 at 12:48 PM, Rick Fochtman rfocht...@ync.net said: IIRC, a PL/I array can start at any subscript between -32767 and +32767. That's an implementation restriction. I don't know whether any current PL/I compiler is so limited. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
In aanlktiklb7bxzr42mzhzxigndkc5d8sctoskee-oj...@mail.gmail.com, on 01/18/2011 at 05:12 PM, Tony Harminc t...@harminc.net said: In passing, I was unpleasantly surprised to find that oorexx supports only 1-origin subscripting for its array class, thus making it very difficult to move from the more general but slower and arguably less rigorous use of stems for collections that would otherwise be a good match for arrays. To say nothing of the complete ideological incompatibility with C/C++ thus created, or at least demonstrated. I don't care about ideological incompatibility with C, but for a language descended from PL/I to have fixed lower bounds in array subscripts is quaint. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
In p062408aec95813a3450b@[192.168.1.11], on 01/15/2011 at 10:32 PM, Robert A. Rosenberg hal9...@panix.com said: Computer Arrays are OFFSETS No. Subscripts are labels, and need not begin from zero or even be contiguous. Thus they start at 0 The Don't in Fortran. They Don't in Algol. They don't in PL/I. It also makes locating them easier No. For a contiguous array, it's easy to locate an element regardless of the subscript origin. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
On 1/17/2011 at 8:34 AM, in message 20110118114036.c1fdcf58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In p062408aec95813a3450b@[192.168.1.11], on 01/15/2011 at 10:32 PM, Robert A. Rosenberg hal9...@panix.com said: Computer Arrays are OFFSETS No. Subscripts are labels, and need not begin from zero or even be contiguous. Thus they start at 0 The Don't in Fortran. They Don't in Algol. They don't in PL/I. Or COBOL! Or Pascal. The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
frank.swarbr...@efirstbank.com (Frank Swarbrick) writes: Or COBOL! Or Pascal. there are large number of characteristics of C language that result in programmers tending to shoot themselves in the foot ... that are not there in other languages. the original mainframe tcp/ip implementation had been done in vs/pascal ... and had none of the buffer-length related exploits (related to buffers and buffer indexing) that have been prevelent in C-language based implementations (it is almost as hard to shoot yourself in the foot with pascal as it is to not shoot yourself with C). of course there were other issues in that original vs/pascal tcp/ip implementation ... getting something like 44kbytes/sec aggregate using loads of processor. I did do the rfc1044 enhancements ... and in some tuning tests at cray research ... got channel speed (1mbyte/sec) thruput on 4341 using only small amount of processor (something like 500 times reduction in instructions executed per byte transferred). misc. past posts http://www.garlic.com/~lynn/subnetwork.html#1044 -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Frank Swarbrick wrote: On 1/17/2011 at 8:34 AM, in message 20110118114036.c1fdcf58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In p062408aec95813a3450b@[192.168.1.11], on 01/15/2011 at 10:32 PM, Robert A. Rosenberg hal9...@panix.com said: Computer Arrays are OFFSETS No. Subscripts are labels, and need not begin from zero or even be contiguous. Thus they start at 0 The Don't in Fortran. They Don't in Algol. They don't in PL/I. Or COBOL! Or Pascal. IIRC, a PL/I array can start at any subscript between -32767 and +32767. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Date representations: Y2k revisited
Rick Fochtman wrote: | IIRC, a PL/I array can start at any subscript between -32767 and +32767 and that was just about correct for early versions of the F Compiler. For later ones for which subscripts could be fullwords it was -2^31 = l = H = +2^31 - 1 -2_147_483_648 = L = H = +2_147_483_647 and this is still the case for the current z/OS Enterprise PL/I Compilers. The difference of 1 in the absolute magnitudes of the two pairs of positive and negative bounds -32_768 = L = H +32_767 -2_147_483_648 = L = h = +2_147_483_647 reflects the use of twos-complement representations and arithmetic, for which 0 is its own twos-complement. Some dialects of FORTRAN now permit this too. C and C++ support only zero-origin subscripting; and they are unlikely, for ideological reasons, to relax this constraint. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
On 18 January 2011 13:57, john gilmore john_w_gilm...@msn.com wrote: C and C++ support only zero-origin subscripting; and they are unlikely, for ideological reasons, to relax this constraint. In passing, I was unpleasantly surprised to find that oorexx supports only 1-origin subscripting for its array class, thus making it very difficult to move from the more general but slower and arguably less rigorous use of stems for collections that would otherwise be a good match for arrays. To say nothing of the complete ideological incompatibility with C/C++ thus created, or at least demonstrated. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
At 04:12 + on 01/10/2011, john gilmore wrote about Re: Date representations: Y2k revisited: Robert A Rosenberg writes: begin snippet It is not as simple as that since you have to allow for calenders getting out of sync. When the Julian calender was replaced by the regorian one, there were (depending on where you were since the switch occurred in different years in different countries) 13 or so days lost. /end snippet No days were lost. John Gilmore Ashland, MA 01721-1817 USA I seem to remember reading about Riots in England when renters who paid their landlords rent by the quarter were charged a full 3 months rent for a 2.5 month quarter. I think that the failure to prorate the rent that quarter since it covered 3 months (even through one of them was only 2 weeks long) qualifies as 13 lost days. OOPS: When I looked up the riots on the Web (so I could give a URL for my reference) I found it was 11 days skipped not 13. I also found that the riots are an urban legend. In fact the law making the change SPECIFICALLY stated that any Tax or Rental Payment was to be due on the equivalent Gregorian Date as the original Julian date (ie: the Gregorian Date that was numbered as 11 days after the pre-reform Julian Date). I'm sure that if you were an employer who paid your employees a flat monthly salary you would want to compensate for a month where you pay them for 4 weeks after they work only 2 weeks due to the calendar changing and the dates being advanced by 13 days (ie: The date after day 10 being the 24th). Thus the legend of the Landlords supposedly wanting to be paid for the non-existent 11 days in the quarter would have some justification if if had actually occurred (and as noted above if a Legislature had not, for once, written the law so as to take into account the consequences of its enactment). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
subscripting (was: Date representations: Y2k revisited)
Robert Rosenberg's notion of European floor-numbering/naming conventions---ground floor, rez-de-chaussée, Erdgeschoß, pianterreno, or the like followed by 1, 2, 3, . . . ---as an instance of zero-origin indexing, and the American convention---1, 2, 3, 4, . . .---that makes the ground floor the first floor, as an instance of one-origin subscripting is drôle and instructive. His view that zero-origin subscripting is simpler than one-origin subscripting is not to me so persuasive. Zero-origin subscripting is perhaps the more fundamental, but both are trivial, and neither exhausts the possible. Arbitrary-origin subscripting is easy to implement, as it is in PL/I, by introducing the idea of a virtual origin, the address where element (0,0,...,0) is located if it exists or would be located if it does not. The whole question whether subscripting conventions and the like should be implicit, embedded in code, or should instead be made explicit in descriptors is indeed still open: descriptor-based schemes have much greater generality and power. What is important is that a novice programmer master the few principles involved very thoroughly, at the cat-brain, quasi-instinctual level at which the mean free path between mistakes in their use is long in relation to his or her working lifetime. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
At 10:38 -0500 on 01/10/2011, Shmuel Metz (Seymour J.) wrote about Re: Date representations: Y2k revisited: Admiral Hopper, who was as mathematician, said that she used one-origin tables when talking to accountants and zero-origin arrays when talking to her quondam Harvard colleagues. One-origin numbering of, e.g., chapters, pages, is the norm in Mathematics texts and papers. For very valid reasons. Books, etc. are ordinal (ie: First, Second, Third, etc so you number them as 1, 2, 3, ...). Computer Arrays are OFFSETS (ie: How many elements past the start of the array). Thus they start at 0 [the origin] and are then the First/Second/etc. element after the initial one. It also makes locating them easier since the location of Element X is X times element length plus the location of the array (no need to decrement the index number or use an address element-length prior to the array location to compensate for one-origin indexing). This Zero Based Offset counting is used in England where the street level floor of a Building is the Ground Floor and the next floor up is the First (not as in the US where it is the Second) Floor. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
At 00:33 -0600 on 01/11/2011, Avram Friedman wrote about Re: Date representations: Y2k revisited: Start of bibical months are observation things ... ie sighting of the new moon. There is also the issue (with some religious calenders) where the start of the new year (or some holiday - I forget) requires a sighting of something in the sky. A cloudy day (or sandstorm g) at the designated observation time would prevent the official designated spotters from seeing and certifying the occurrence and thus postpone the event until they can do their job after the weather clears up. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
In 144dc28cdd874c74957fe7bcb4e17...@ownerpc, on 01/10/2011 at 01:23 PM, Tony's FRONTIER account tbabo...@frontier.com said: OK, so there's words appearing that not all of us recognize, so what? While I would have appreciated translations of the Latin (Italian?) words, I saw nothing arrogant or condescending there. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
In 1230868823-1294668848-cardhu_decombobulator_blackberry.rim.net-13100425...@bda506.bisx.prod.on.blackberry, on 01/10/2011 at 02:14 PM, Ted MacNEIL eamacn...@yahoo.ca said: arrogance. PKB. If somebody does not understand the written words, it is not the reader's fault. Nonsense. It's often the reader's fault. Your posts just show your high oipinion (sic) of yourself; something not shared by many. He doesn't have to run faster than the bear; he just has to run faster than you. I'm going to avail myself of the opportunity you suggested and update my kill list. I'm sure he's broken hearted. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Avram Friedman wrote | If I may Measuring time is not science or math based, it is observation based. followed by a recapitulation of some of the features of the Hebrew religious calendar. (This calendar is treated systematically in chapter 9 of Dershowitz and Reingold, Calendrical calculations.) Now science is observation-based, but what Mr Friedman has in mind is naif, local , naked-eye observation. This tension between a promulgated, official calendar and local observation is a very old one. In the United States different local times, fixed with attention to local latitude and longitude coordinates, were the rule in essentially all communities until the middle of the nineteenth century, when the coming of the telegraph and railroads brought time zones and inexorable standardization. The Hebrew calendar is a lunisolar one, and like all of them it attempts to reconcile the irreconcilable: the orbit of the earth about the sun and that of the moon about the earth are not simply related. The Islamic calendar, on the other hand, is an all but pure lunar one, and there is a Koranic injunction against the use of leap months like those inserted inoto the gravid or embolismic years of the Hebrew calendar. (The Islamic calendar does have leap days of a sort, but that is another matter.) In Moslem countries a civil calendar, typically--except for Iran and Afghanistan--the Gregorian calendar, is used for most purposes, with the Islamic calendar reserved for ritual, religious purposes. Ramadan (Ramazam), for example, begins and ends when the relevant new moons are actually observed locally. This exclusively lunar scheme---An Islamic-calendar year contains a mean of only 354.3... days as opposed to the mean of 365.2425 days in a Gregorian year---is not synchronized with the seasons. This precession would perhaps be a fatal disadvantage if this calendar were used for secular purposes, but for religious purposes it is perceived to be an advantage: the fasting rigors of Ramadan fall sometimes in winter and sometimes in summer, and they are not uniformly more onerous in some parts of the world than they are elsewhere. For secular purposes, however, a precise lunisolar calendar is a necessity, and the science of the National Observatories underlies it. Naif local observation cannot and does not play any role in the maintenance of the modern Gregorian calendar. One of the perhaps obvious advantages of the Day Serial Numbers (DSNs) that I described in earlier posts is just that they make date conversions between two calendars, even two such different ones as the Gregorian and Islamic calendars, trivial: Day 1 of the Islamic calendar is---It began at sundown on Thursday---Friday, July 16th, 622 CE of the Julian calendar. This Julian calendar date has the Gregorian DSN 227015. Et voilà! The conversion is in effect accomplished. It would be disingenuous not to concede the religious and the scientific temper are often in sharp conflict, but no religious observance need be compromised in any way by the use of a scientific, secular calendar for secular purposes. Religious observances are even facilitated by the availability of secular-calendar estimates of the most probable dates of events like Ramadan and the Islamic New Year (Muharram 1). What is needed is some considerable understanding of the structural differences among calendars: A perhaps not quite obvious consequence of the relative shortness of the Islamic-calendar year is that annual Islamic holidays can occur twice in a Gregorian year; or again certain Jewish holidays---minor, non-seasonal ones fortunately---do not occur at all in some few Gregorian years. Anomalies of this sort can be disconcerting to the uninformed. More important, they impose design requirements on programs. Calendrical routines that determine the Gregorian dates of other-calendar holidays must in general be prepared not for a result that is a single scalar date|DSN but for one that is a vector of zero, one, or two dates|DSNs. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Actually, I don't care what you write in. Sometimes I understand your posts, sometimes I don't. I have to see some evidence of payoff before I research bombastic vocabulary. But as for English: I'm pretty sure en petit is French and Mirriam-Webster doesn't show it. I thought jejune was French also but M-W has that so I did learn one new English word. I wonder if the opportunity to use it will arrive before it fades from memory. Coloro che sanno is apparently Latin. You identified dietrologia as Italian. Your remedy is an equal opportunity one. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of john gilmore Sent: Sunday, January 09, 2011 2:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Date representations: Y2k revisited snip All this is by the way. Mr Schwarz wants me to write my posts in a species of subliterate English he judges appropriate. I demur, as I have in the past; and, as I have noted in the past too, he has an immediate remedy at hand. He can put my email address on his kill list, which will make me an unperson to him and spare him the sight of my posts. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Coloro che sanno sounds more Italian to me... but then I don't know Italian. :-) Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Sam Siegel On Sun, Jan 9, 2011 at 8:12 PM, john gilmore john_w_gilm...@msn.com wrote: [ a lot ] Thank you (once again) for making irrelevant points about useless trivia. Regardless of how we arrived at having multiple formats for storing dates internally, these formats exist and need to be managed. For those of us who are actual practitioners of the art, with day-to-day responsibility for keeping systems up and running, versus ivory tower poets, it is well known that superior methods exist but for many practical reasons (ROI, resource constraints, risk, time-to-market for new facilities, etc. ad- nauseam) cannot be implemented. It does no good to chide others about what they do not control and cannot change with comments about a superior way of doing things. Those methods are only superior if they can actually be implemented. What is helpful is to provide practical assistance to resolve problems. And when the times comes, provide assistance in implementing new methods should that level of re-engineering become feasible. In the venacular, be a team member instead of an armchair quarterback. In effect, you have just said Shut up to our very own Wizard of Oz. :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Joel Ewing's responses to my strictures were, as I expected them to be, wholly predictable in character. Dates, even those in the comparatively respectable FIPs- and ANSI-compatible Gregorian descending character-string, mmdd, format inevitably get used; and when they are used ad hoc disaster follows with the same inevitability. Such questions as o what is the day of the week of the date mmdd? o what is the date MMDD ten business days following the date mmdd? o how many business|working days are available between MMDD and mmdd? get asked and answered very badly when a format not designed for computation is used. (I have a rogue's gallery/black museum of COBOL and C and PL/I routines, written by people whose knowledge of calendrical computations was inadequate, that 1) are wrong from time to time and 2) obtain their results using schemes that are so convoluted and bizarre as to be all but unbelievable, unless of course one has seen probability problems approached by undergraduates who have not yet been taught what a Jacobian is.) For reasons that elude me programmers who would never attempt to write their own cosh or present-value subroutine have the chutzpah to do calendrical computations badly. Some of what Mr Ewing says is simply wrong. It does not really matter what epoch origin is chosen provided trhat an organization chooses and adheres to one. Conversions are then trivial. Or again, the argument that a DSN having an unknown epoch origin is opaque while a mmdd value is not is simply naif. Incompletely or inadequately documented routines are, of course, problematic; but they are problematic in a generic way; and the remedy for them is better documentation not adherence to obsolete internal date formats. The Y2k problem provided an opportunity to solve problems that was shirked. Date-processing problems that should have been addressed with respectable technology were instead papered over with dubious windowing schemes and the like. What is past is prologue, and I know of no organization that did significant Y2k remediation that is not now living with the disagreeable consequences of having done it badly. But enough! I have said what I wished to say about this problem. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Whilst struggling through the latest installments of this somewhat dry and dusty thread, I happened to be watching a rerun of a BBC show titled What time is it ?. Without meaning to be too rude, I must admit I found the discussion of quantum and string theory and (potential) parallel universes eminently more interesting than reading about competing calendars. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
All this is by the way. Mr Schwarz wants me to write my posts in a species of subliterate English he judges appropriate. I demur Of course you do! Most people communicate to communicate. You communicate to show off your arrogance. If somebody does not understand the written words, it is not the reader's fault. Rather, it's the author's. Your posts just show your high oipinion of yourself; something not shared by many. I don't care, this time, if this is considered an ad hominem attack. And, I'm not going to bother to make any more responses to this thread, nor you. I'm going to avail myself of the opportunity you suggested and update my kill list. - Ted MacNEIL eamacn...@yahoo.ca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
In snt113-w614e7c80dd20c171926de4c6...@phx.gbl, on 01/09/2011 at 10:20 PM, john gilmore john_w_gilm...@msn.com said: Admiral Hopper, who was as mathematician, said that she used one-origin tables when talking to accountants and zero-origin arrays when talking to her quondam Harvard colleagues. One-origin numbering of, e.g., chapters, pages, is the norm in Mathematics texts and papers. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Many of us have posted complaints about mainframe technical questions that could have been easily answered with only a modicum of self-directed research, commonly known as RTFM, on the part of the OP. This same helpful hint applies equally to the non-mainframe-specific portion of a post. Instead of chiding others for not deliberately dumbing down their writing to my inferior level of English fluency, I often (but don't always) remember to research the unknown before asking the entire IBM-MAIN subscriber list to explain it to me or to sympathize with my emotion or abridged vocabulary. The first time I encountered the phrase coloro che sanno in a John Gilmore post a few years ago, I used Google to understand the phrase before sheepishly exposing, or proudly proclaiming, my ignorance to all of IBM-MAIN. I have also used Google many times to decode urban slang, texting abbreviations, arcane English words, and many other foreign words and phrases that appear in posts. Having done some research into calendars long ago, I found much of the calendar thread very interesting. I would also like to learn more about quantum and string theories, mainframe architecture, DASD, new instructions, XCF, Italian, and ten thousand other topics. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shane Sent: Monday, January 10, 2011 7:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Date representations: Y2k revisited Whilst struggling through the latest installments of this somewhat dry and dusty thread, I happened to be watching a rerun of a BBC show titled What time is it ?. Without meaning to be too rude, I must admit I found the discussion of quantum and string theory and (potential) parallel universes eminently more interesting than reading about competing calendars. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
On Mon, Jan 10, 2011 at 9:11 AM, Bill Fairchild bi...@mainstar.com wrote: Many of us have posted complaints about mainframe technical questions that could have been easily answered with only a modicum of self-directed research, commonly known as RTFM, on the part of the OP. This same helpful hint applies equally to the non-mainframe-specific portion of a post. Instead of chiding others for not deliberately dumbing down their writing to my inferior level of English fluency, I often (but don't always) remember to research the unknown before asking the entire IBM-MAIN subscriber list to explain it to me or to sympathize with my emotion or abridged vocabulary. The first time I encountered the phrase coloro che sanno in a John Gilmore post a few years ago, I used Google to understand the phrase before sheepishly exposing, or proudly proclaiming, my ignorance to all of IBM-MAIN. I have also used Google many times to decode urban slang, texting abbreviations, arcane English words, and many other foreign words and phrases that appear in posts. Having done some research into calendars long ago, I found much of the calendar thread very interesting. I would also like to learn more about quantum and string theories, mainframe architecture, DASD, new instructions, XCF, Italian, and ten thousand other topics. Bill, I lookup each word / phrase also. It is very educational. It is the thin skinned, condescending, arrogant, chip-on-the-shoulder and holier-than-thou manner in which they are delivered, along with the consistent rejection that there are other possibility sufficiently correct answers that make Gilmore's posts unpalatable. Sam Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shane Sent: Monday, January 10, 2011 7:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Date representations: Y2k revisited Whilst struggling through the latest installments of this somewhat dry and dusty thread, I happened to be watching a rerun of a BBC show titled What time is it ?. Without meaning to be too rude, I must admit I found the discussion of quantum and string theory and (potential) parallel universes eminently more interesting than reading about competing calendars. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Agreed. On Mon, Jan 10, 2011 at 12:52 PM, Sam Siegel s...@pscsi.net wrote: On Mon, Jan 10, 2011 at 9:11 AM, Bill Fairchild bi...@mainstar.com wrote: Many of us have posted complaints about mainframe technical questions that could have been easily answered with only a modicum of self-directed research, commonly known as RTFM, on the part of the OP. This same helpful hint applies equally to the non-mainframe-specific portion of a post. Instead of chiding others for not deliberately dumbing down their writing to my inferior level of English fluency, I often (but don't always) remember to research the unknown before asking the entire IBM-MAIN subscriber list to explain it to me or to sympathize with my emotion or abridged vocabulary. The first time I encountered the phrase coloro che sanno in a John Gilmore post a few years ago, I used Google to understand the phrase before sheepishly exposing, or proudly proclaiming, my ignorance to all of IBM-MAIN. I have also used Google many times to decode urban slang, texting abbreviations, arcane English words, and many other foreign words and phrases that appear in posts. Having done some research into calendars long ago, I found much of the calendar thread very interesting. I would also like to learn more about quantum and string theories, mainframe architecture, DASD, new instructions, XCF, Italian, and ten thousand other topics. Bill, I lookup each word / phrase also. It is very educational. It is the thin skinned, condescending, arrogant, chip-on-the-shoulder and holier-than-thou manner in which they are delivered, along with the consistent rejection that there are other possibility sufficiently correct answers that make Gilmore's posts unpalatable. Sam Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shane Sent: Monday, January 10, 2011 7:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Date representations: Y2k revisited Whilst struggling through the latest installments of this somewhat dry and dusty thread, I happened to be watching a rerun of a BBC show titled What time is it ?. Without meaning to be too rude, I must admit I found the discussion of quantum and string theory and (potential) parallel universes eminently more interesting than reading about competing calendars. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Hey everybody, let's calm down a piece. I post very infrequently and on even more infrequent occasions when JG commented, he was nice to me. OK, so there's words appearing that not all of us recognize, so what? I've googled to build my own knowledge of English (which I boast is well enough already) and treated the opportunity as simply that, an opportunity. And, just a few weeks ago he treated us to a poem! It made my (hopefully Friday) afternoon. P.S. I considered the adjective highfalutin to describe certain words in past posts, but upon looking it up I found it inappropriate. I hope others do as well, though I will always respect opinions contrary to mine. TB. snipping started Many of us have posted complaints about mainframe technical questions that could have been easily answered with only a modicum of self-directed research, commonly known as RTFM, on the part of the OP. This same helpful snipping ended. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Tony's FRONTIER account wrote: Hey everybody, let's calm down a piece. At last. when John Gilmore commented, No one in IBM-MAIN can stay neutral [1] when he post. ;-D I'm outta this thread before Big D chimes in this off-topic thread. Groete / Greetings Elardus Engelbrecht [1] - It is hard work to be neutral. the *other* party thinks I'm on their enemy's side sigh ;-D -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
If I may Mesuring time is not science or math based, it is observation based. For example in the judeo-christran tradition ... There was night and there was day, the first day. Start of bibical months are observation things ... ie sighting of the new moon. Even in the observation mode there are counting difficulties. For example Passover / Easter occurs in the bibical 15th day of Nissan but is also said to occur in the spring of the year. The difficulty is lunar years and solar years (that control the seasons) only align every 50 lunar years so. To make things work for the bean counters a month is added to the lunar year from time to time but this distroys the sabaticial year cycle of things aligning every 50 years and special bibically proscribed practices for the alignment. Ignoring for a moment that there are problems with the observational method the demands of the modren world (meaning the last 2000 years or so) might be better served by a science or math solution. Such a system has many advantages but is in fact an additional source of mesurement error. Once again telling time is neither math or science based. Attempts to distort this reality have many advantages and disadvantages. Lots of this thread is based on the faulty assumption that there is a scientific or math related correct solution to an observation problem. Avram Friedman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Date representations: Y2k revisited
I have been bemused by the Ewing-Gilmartin debate on date representations. It recapitulates en petit a good many of the jejune Y2k discussions of the past, complete with their defenses of the indefensible and their characteristic crackpot realism. Perhaps even more seriously, it omits to distinguish between o internal date formats suitable for computation, and o external date formats, suitable for display to humans or printing. External formats vary from culture to culture. Even within the Anglo-American community 'September 2 1925' is universally intelligible but '2 ix 1925' astonishres many Americans. Internal date formats are much simpler and not at all controversial among coloro che sanno. Choose an epoch origin, the putative birth date of Jesus, that of the Moslem hegira, Scaliger's -4713 January 1 BCE, whatever; give it the serial number +1, its predecessor days the serial number 0, -1, -2, . . . , and its successor days the serial numbers +2, +3, +4, . . . Whatever your choice, conversion to someone else's choice is trivial; a single addition|subtraction suffices. Using DSNs trivializes calendar arithmetic. Moreover, the conversions o DSN to somebody's calendar o somebody's calendar to DSN are easy too, although they should be encapsulated in subroutines written by a calendrical-arithmetic specialist (for the same reasons that a sqrt subroutine should be written by an approximations specialist). DSNs represented as signed binary fullword values encompass an interval of 5,879,610 Gregorian years on both sides of the epoch origin chosen, which is adequate for most practical purposes, but not for geological or astronomical applications, for which signed binary doubleword values are required. Why are these four-byte internal date representations not in wide use? Everyone who knows enough about calendars and dates to have a right to an opinion agrees that they should be used exclusively. Why then has this rare consensus been systematically ignored by the unwashed? The usual suspects, sloth and ignorance, decisions made by people unqualified to make them, are, I suppose, sufficient to explain this avoidance of DSNs. There is probably no need to invoke the resources of that science the Italians call dietrologia to identify a villain. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Apparently a camouflaged attempt to instigate a denial of service attack against several of the more popular on line dictionaries and possibly search engines also. Declining to participate, I cannot tell if astonishres is a typo or just another example of my limited vocabulary. I also wonder what dataset names have to do with dates and calendars and why the epoch origin should be 1 and not 0. Why would astronomical or geological efforts require doublewords? Has anyone ever seen any time value larger than 5 million years which requires granularity down to the day? month? single year? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of john gilmore Sent: Sunday, January 09, 2011 8:37 AM To: IBM-MAIN@bama.ua.edu Subject: Date representations: Y2k revisited I have been bemused by the Ewing-Gilmartin debate on date representations. It recapitulates en petit a good many of the jejune Y2k discussions of the past, complete with their defenses of the indefensible and their characteristic crackpot realism. Perhaps even more seriously, it omits to distinguish between o internal date formats suitable for computation, and o external date formats, suitable for display to humans or printing. External formats vary from culture to culture. Even within the Anglo-American community 'September 2 1925' is universally intelligible but '2 ix 1925' astonishres many Americans. Internal date formats are much simpler and not at all controversial among coloro che sanno. Choose an epoch origin, the putative birth date of Jesus, that of the Moslem hegira, Scaliger's -4713 January 1 BCE, whatever; give it the serial number +1, its predecessor days the serial number 0, -1, -2, . . . , and its successor days the serial numbers +2, +3, +4, . . . Whatever your choice, conversion to someone else's choice is trivial; a single addition|subtraction suffices. Using DSNs trivializes calendar arithmetic. Moreover, the conversions o DSN to somebody's calendar o somebody's calendar to DSN are easy too, although they should be encapsulated in subroutines written by a calendrical-arithmetic specialist (for the same reasons that a sqrt subroutine should be written by an approximations specialist). DSNs represented as signed binary fullword values encompass an interval of 5,879,610 Gregorian years on both sides of the epoch origin chosen, which is adequate for most practical purposes, but not for geological or astronomical applications, for which signed binary doubleword values are required. Why are these four-byte internal date representations not in wide use? Everyone who knows enough about calendars and dates to have a right to an opinion agrees that they should be used exclusively. Why then has this rare consensus been systematically ignored by the unwashed? The usual suspects, sloth and ignorance, decisions made by people unqualified to make them, are, I suppose, sufficient to explain this avoidance of DSNs. There is probably no need to invoke the resources of that science the Italians call dietrologia to identify a villain. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
On Sun, 9 Jan 2011 11:58:41 -0800, Schwarz, Barry A wrote: I also wonder what dataset names have to do with dates and calendars and why the epoch origin should be 1 and not 0. Day Serial Number. Kinda like USS. Why would astronomical or geological efforts require doublewords? Has anyone ever seen any time value larger than 5 million years which requires granularity down to the day? month? single year? Would you, then, propose a floating point representation that allows a tradeoff between range and precision? What would you propose as the epoch at which it has greatest precision? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Mr Schwarz's comments are a mixed bag. His conjectured typo was a typo, and it would be rude for me to comment further on the paucity of his vocabularity, of which I should in any case need a larger sample to make a judgment. DSN is a systematically ambiguous acronym. In the context in which I used it it denotes Day Serial Number; in an MVS data-management context it denotes DataSet Name; in at least one bird-watching context it denotes Daily Sightings News; etc., etc. Are there dates more than 5 million years in the future or past that can be known with great precision. The answer is yes, at least for such astronomical event as eclipses, which can be known outside this interval to the hour and minute. For many other events such precision would be delusive, but even approximations must often be used in arithmetic expressions in which values that are known with great precision also figure, and for this purpose they must be expressed in the same way. An example will; help here. Suppose that a news service reports a bank raid in Nottingham that netted the miscreants £5000. It may then be reported an American newspaper as a bank robbery that netted them $7774, the spurious precision of this second result having resulted from the use of the [current] exchange rate £1 = US$1.5548. We mostly lack conventions for dealing with such issues, chiefly because they are difficult to explain to the untutored. [There are, of course, contexts in which we do have such conventions. Consider two of Cantor's transfinite numbers, T and t, T t. Then T + t = T. The sum of two transfinite numbers is the larger, and in general sum(t(i), i = 1, 2, . . . , N) = max(t(i)). Regrettably, These and similar devices need too much explication to be at all readily portable.] The question whether zero-origin or one-origin values should be used in some context is an old one. The traditional Gregorian year progression is still . . . ,2 BC, 1 BC, AD 1, AD 2, . . . It goes from 1 BC to AD 1 without passing through a zeroth year or collecting $200. The astronomical Julian calendar, on the other hand, has a zeroth year. Or again COBOL uses one-origin subscripting for tables; and C uses zero-origin subscripting for arrays. Asked about this difference, Admiral Hopper, who was as mathematician, said that she used one-origin tables when talking to accountants and zero-origin arrays when talking to her quondam Harvard colleagues. Context is all! All this is by the way. Mr Schwarz wants me to write my posts in a species of subliterate English he judges appropriate. I demur, as I have in the past; and, as I have noted in the past too, he has an immediate remedy at hand. He can put my email address on his kill list, which will make me an unperson to him and spare him the sight of my posts. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
snip Mr Schwarz wants me to write my posts in a species of subliterate English he judges appropriate. unsnip A very smart man said: Everything should be made as simple as possible, but not simpler. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
At 4:36 PM + on 01/09/2011, john gilmore wrote about Date representations: Y2k revisited: Internal date formats are much simpler and not at all controversial among coloro che sanno. Choose an epoch origin, the putative birth date of Jesus, that of the Moslem hegira, Scaliger's -4713 January 1 BCE, whatever; give it the serial number +1, its predecessor days the serial number 0, -1, -2, . . . , and its successor days the serial numbers +2, +3, +4, . . . Whatever your choice, conversion to someone else's choice is trivial; a single addition|subtraction suffices. It is not as simple as that since you have to allow for calenders getting out of sync. When the Julian calender was replaced by the Gregorian one, there were (depending on where you were since the switch occurred in different years in different countries) 13 or so days lost. There is also the issue that the length of the years has varied so that saying the day number x is date y in the calendar can be difficult (all years were not 365/366 days long). Then there is the issue of when leap years occur. Author Isaac Asimov write a mystery story (Year of the Action) about when the Gilbert and Sullivan Operetta Pirates of Penzance was set. All that is stated in the play is that one of the characters who was born on February 29 would celebrate his 21st birthday in 1940. The play occurs on the 21st anniversary of his birth (at which point he is 5.25 Birthdays Old). If he was born in 1856 (84 years before 1940) then the play was set in 1877. The problem is that 1900 was NOT a leap year which if the 1940 year is accurate would push the birth date back to 1852 and thus the Year of the Action to 1873. The mystery was to decide from the other dialog on the year 1873 (which would not count 1900 as a leap year) or 1877 (which would assume that Gilbert goofed and was unaware of the problem with 1900). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
Robert A Rosenberg writes: begin snippet It is not as simple as that since you have to allow for calenders getting out of sync. When the Julian calender was replaced by the regorian one, there were (depending on where you were since the switch occurred in different years in different countries) 13 or so days lost. /end snippet thus inadvertently proving my point. No days were lost. The Roman calendar was not replaced by the Gregorian calendar. The new Gregorian calendar simply became the official civil and religious calendar in some jurisdictions (at different times) The Roman calendar did not cease to exist. It indeed continues in use: The Orthodox Church still fixes the date of Easter in it. Many calendars coexist at any point in time, and so-called proleptic dates, which fall before the epoch origin of some calendar, can always be assigned earlier events in that calendar. (One can, for example, date the assassination of Julius Caesar in the French Revolutionary Calendar, the epoch origin of which is 1792 September 22 in the Gregorian calendar and 1792 September 11 in the Roman calendar.) Mr. Rosenberg, an able man who makes valuable contributions to this forum, has thus convicted himself out of his own mouth of knowing very little about calendars. Worse, much of what he thinks he knows is, as is often the case, wrong. Even worse, he has not though it necessary or even desirable to think at all hard about these questions. If he had he would not be retailing the absurd notion of lost days. Christoph Clavius's definitive treatment of the Gregorian calendar is, regrettably, in untranslated Latin; and this makes it inaccessible to Latin dropouts. The standard modern reference, which I have cited here before, is Dershowitz, Nachum, and Edward M. Reingold, Calendrical calculations, Cambridge: Cambridge University Press, 1997. Their book is in accessible modern English, and it were better to read it carefully and to study the LISP routines it contains with attention before pontificating about dates and calendars. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
On Sun, Jan 9, 2011 at 8:12 PM, john gilmore john_w_gilm...@msn.com wrote: Robert A Rosenberg writes: begin snippet It is not as simple as that since you have to allow for calenders getting out of sync. When the Julian calender was replaced by the regorian one, there were (depending on where you were since the switch occurred in different years in different countries) 13 or so days lost. /end snippet thus inadvertently proving my point. No days were lost. The Roman calendar was not replaced by the Gregorian calendar. The new Gregorian calendar simply became the official civil and religious calendar in some jurisdictions (at different times) The Roman calendar did not cease to exist. It indeed continues in use: The Orthodox Church still fixes the date of Easter in it. Many calendars coexist at any point in time, and so-called proleptic dates, which fall before the epoch origin of some calendar, can always be assigned earlier events in that calendar. (One can, for example, date the assassination of Julius Caesar in the French Revolutionary Calendar, the epoch origin of which is 1792 September 22 in the Gregorian calendar and 1792 September 11 in the Roman calendar.) Mr. Rosenberg, an able man who makes valuable contributions to this forum, has thus convicted himself out of his own mouth of knowing very little about calendars. Worse, much of what he thinks he knows is, as is often the case, wrong. Even worse, he has not though it necessary or even desirable to think at all hard about these questions. If he had he would not be retailing the absurd notion of lost days. Christoph Clavius's definitive treatment of the Gregorian calendar is, regrettably, in untranslated Latin; and this makes it inaccessible to Latin dropouts. The standard modern reference, which I have cited here before, is Dershowitz, Nachum, and Edward M. Reingold, Calendrical calculations, Cambridge: Cambridge University Press, 1997. Their book is in accessible modern English, and it were better to read it carefully and to study the LISP routines it contains with attention before pontificating about dates and calendars. Thank you (once again) for making irrelevant points about useless trivia. Regardless of how we arrived at having multiple formats for storing dates internally, these formats exist and need to be managed. For those of us who are actual practitioners of the art, with day-to-day responsibility for keeping systems up and running, versus ivory tower poets, it is well known that superior methods exist but for many practical reasons (ROI, resource constraints, risk, time-to-market for new facilities, etc. ad- nauseam) cannot be implemented. It does no good to chide others about what they do not control and cannot change with comments about a superior way of doing things. Those methods are only superior if they can actually be implemented. What is helpful is to provide practical assistance to resolve problems. And when the times comes, provide assistance in implementing new methods should that level of re-engineering become feasible. In the venacular, be a team member instead of an armchair quarterback. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date representations: Y2k revisited
On 01/09/2011 10:36 AM, john gilmore wrote: I have been bemused by the Ewing-Gilmartin debate on date representations. It recapitulates en petit a good many of the jejune Y2k discussions of the past, complete with their defenses of the indefensible and their characteristic crackpot realism. Perhaps even more seriously, it omits to distinguish between o internal date formats suitable for computation, and o external date formats, suitable for display to humans or printing. External formats vary from culture to culture. Even within the Anglo-American community 'September 2 1925' is universally intelligible but '2 ix 1925' astonishres many Americans. Internal date formats are much simpler and not at all controversial among coloro che sanno. Choose an epoch origin, the putative birth date of Jesus, that of the Moslem hegira, Scaliger's -4713 January 1 BCE, whatever; give it the serial number +1, its predecessor days the serial number 0, -1, -2, . . . , and its successor days the serial numbers +2, +3, +4, . . . Whatever your choice, conversion to someone else's choice is trivial; a single addition|subtraction suffices. Using DSNs trivializes calendar arithmetic. Moreover, the conversions o DSN tosomebody's calendar osomebody's calendar to DSN are easy too, although they should be encapsulated in subroutines written by a calendrical-arithmetic specialist (for the same reasons that a sqrt subroutine should be written by an approximations specialist). DSNs represented as signed binary fullword values encompass an interval of 5,879,610 Gregorian years on both sides of the epoch origin chosen, which is adequate for most practical purposes, but not for geological or astronomical applications, for which signed binary doubleword values are required. Why are these four-byte internal date representations not in wide use? Everyone who knows enough about calendars and dates to have a right to an opinion agrees that they should be used exclusively. Why then has this rare consensus been systematically ignored by the unwashed? The usual suspects, sloth and ignorance, decisions made by people unqualified to make them, are, I suppose, sufficient to explain this avoidance of DSNs. There is probably no need to invoke the resources of that science the Italians call dietrologia to identify a villain. John Gilmore Ashland, MA 01721-1817 USA ... John, I respect your breadth of knowledge in many areas, but unless this is merely intended as very subtle humor, this is way over the top. Perhaps there may be consensus that the most storage-efficient date representation is an integer Date Sequence Number (D.S.N.); but there is certainly no clear consensus on what the origin date should be, and storage efficiency is not the only consideration. As you point out there are many potential choices for origin, and the prospect of having to deal with D.S.N. fields from many different sources, with potentially conflicting choice of origin points is an error waiting to happen. On the other hand, the existence of government sanctioned civil calendars does requires that external interfaces deal with dates in formats based on those calendars, and in many cases this makes internal date representations directly based on those date formats a natural choice. The choice of best internal data representations in all cases, including dates, depends on the manner in which the data will be manipulated. The only fixed requirement is that the representation should be as unambiguous as the original source of data. If the only requirement is merely to save and return a date exactly as it was originally recorded on a civil document, changing the internal representation may just be an unjustified waste of resources. If the primary manner in which the date will be manipulated depends on relationships with the Gregorian form of the date, it may also be the case that internal representations directly based on the Gregorian Date are the most computationally efficient. It is demonstrably false to imply that D.S.N. internal representations should be used exclusively, much less imply sloth, ignorance, and lack of training as the only grounds for disagreement with that position. Over the decades there have been many cases where I have had to deduce the interpretation of fields in records where adequate documentation was no longer available. When the fields represented dates in formats directly based on Gregorian Dates, given sufficient number of examples it was always possible to arrive at a correct interpretation. Had these fields been integer D.S.N. representations of dates with unknown origin point, there is nothing in the date representation to give any clue as to correct interpretation. Sometimes the redundancy in less efficient date representations is an advantage. I don't have anything against D.S.N. date representations and use them where appropriate; but they are
