HP Forum Archive 19

[ Return to Index | Top of Index ]

12c date range Message #1 Posted by Don Shepherd on 9 Nov 2010, 1:52 p.m. The valid range of dates on a 12c is Oct 15, 1582 to Nov 25, 4046. I understand why the beginning of the range is what it is, but why is the end Nov 25, 4046? That's exactly 899,999 days, which leads me to believe that the date range had some limitation based upon memory size, but does anyone have an insight into this? Edited: 9 Nov 2010, 1:52 p.m.

Re: 12c date range Message #2 Posted by Thomas Klemm on 9 Nov 2010, 3:17 p.m., in response to message #1 by Don Shepherd Quote: No computer has been programmed for correct dates after 28 Feb. 4000 A.D. because there is no consensus on whether that year will be a leap-year. The HP-12C financial calculator thinks it will, and recognizes dates from 15 Oct. 1582 until Sun. 25 Nov. 4046 ; will the world end then?  cf. DAYDATE: Computing Days between Dates Most of us know the author: Prof. W. Kahan

Re: 12c date range Message #3 Posted by David Hayden on 9 Nov 2010, 5:23 p.m., in response to message #2 by Thomas Klemm Here's a fascinating bit of trivia that I learned recently: a year is NOT measured as one revolution of the earth around the sun. Technically, one year is the time from spring equinox to spring equinox (or was it solstice to solstice?). In this way, the seasons remain constant relative to the calendar, even as the earth precesses in it's orbit. So in several thousand years when Orion is visible during warm summer nights, the calendar will say it's July, not January. Dave

Re: 12c date range Message #4 Posted by Jim Horn on 9 Nov 2010, 6:35 p.m., in response to message #2 by Thomas Klemm Wow, thanks for the great pointer to Professor Kahan's note! A quote from it struck me: "Programs that convert invalid data into plausible results are deceitful." Though that has been creatively ignored before (the LearFan's first flight was certified as "December 32, 1980" to meet a deadline). At the HHC1982(?) conference, his talk on numeric integration resulted in a standing ovation. His ability to clarify obscurities and explain things were unforgettable.

Re: 12c date range Message #5 Posted by Don Shepherd on 9 Nov 2010, 7:07 p.m., in response to message #2 by Thomas Klemm Thanks for the link, Thomas. Great stuff. Quote: will the world end then? It looks like Dr. Kahan wondered about that 4046 date too!

Re: 12c date range Message #6 Posted by Katie Wasserman on 9 Nov 2010, 7:53 p.m., in response to message #5 by Don Shepherd Interesting, but this doens't address Don's question. Why limit date calculations to 899,999 days? I took a guess that this is just about what would fit in one-half of a register and that perhaps the other half was needed for some financial calculation function. -Katie

Re: 12c date range Message #7 Posted by Thomas Klemm on 9 Nov 2010, 9:35 p.m., in response to message #6 by Katie Wasserman It's not clear now whether 4000 will be a leap year or not. This makes 2/28/4000 the last possible date we know for sure. Therefore the limit should be 882'928 instead of 900'000 but the latter number is cheaper to enter. Just my guess however. Looking at the code might clarify that matter.

Re: 12c date range Message #8 Posted by Gerson W. Barbosa on 10 Nov 2010, 5:34 a.m., in response to message #7 by Thomas Klemm According to the HP-12C, 4000 will be a leap year: 1.014 1.014001 DeltaDYS -> 366 http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=78807 (Message #23)

Re: 12c date range Message #9 Posted by Katie Wasserman on 10 Nov 2010, 9:32 a.m., in response to message #8 by Gerson W. Barbosa The leap year or not question for 4000 is moot. It will be stardate 1677158 thru 1677163 on what we now call 2/28/4000 thru 2/29/4000.

Re: 12c date range Message #10 Posted by Jeff O. on 10 Nov 2010, 3:50 p.m., in response to message #9 by Katie Wasserman Hmmm.... I question the "accuracy" of the calculator at the link you provided. The earliest stardate from Star Trek TOS is 1312.4 and the latest is 5943.7, which would be April 24, 2324 through December 11, 2328 as calculated by your reference. I thought the original series occurred in the mid-23rd century, with Star Trek TNG in the 24th century. According to a well-known on-line resource whose accuracy is the subject of debate, the various series occurred in the following Gregorian time periods: TOS: mid to late 23rd century TNG: 2364–2370 DS9: 2369–2375 Voyager: 2371–2378 Enterprise: ~2150s Of course the problem is that the “stardate” system was not a rigorously defined system. But in any case, Live Long and Prosper! ... Edited: 22 Nov 2010, 9:00 p.m.

Re: 12c date range Message #11 Posted by Don Shepherd on 10 Nov 2010, 3:51 p.m., in response to message #7 by Thomas Klemm Quote: Looking at the code might clarify that matter. I agree. Does anyone have access to it? This is not earth-shaking, of course, just a matter of curiousity. I saw the upper limit in the 12c manual years ago and always wondered where they came up with that particular date. Like Katie said, it probably has something to do with a limitation on the available RAM or ROM on the 12c.

Re: 12c date range Message #12 Posted by Gerson W. Barbosa on 10 Nov 2010, 5:03 p.m., in response to message #11 by Don Shepherd From Hewlett-Packard Journal, October 1977, page 27: "These functions accept dates from October 15, 1582 to November 25, 4046. ... The second date is determined by internal register limitations, not by any special knowledge of the future." http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1977-10.pdf

Re: 12c date range Message #13 Posted by Fred Lusk on 10 Nov 2010, 5:53 p.m., in response to message #12 by Gerson W. Barbosa So the Mayan calendar has nothing to do with it? :-)

Re: 12c date range Message #14 Posted by Martin Pinckney on 10 Nov 2010, 6:35 p.m., in response to message #13 by Fred Lusk Aha! So you are still lurking on this Forum, but still have not ported Feet-Inches-Fractions Calculator to the 42s? [:-) Actually, I found the exchange between you and Kelley back in Oct. 2005, wherein you described the changes necessary to get the program to run on the 42s, but I have not had time myself to try this.

Re: 12c date range Message #15 Posted by Don Shepherd on 10 Nov 2010, 7:38 p.m., in response to message #12 by Gerson W. Barbosa Thanks Gerson, you 'da man. And thanks to Roy Martin for enlightening us 33 years later!

Re: 12c date range Message #16 Posted by Gerson W. Barbosa on 11 Nov 2010, 5:27 a.m., in response to message #15 by Don Shepherd Don, I didn't even know the HP-12C had this limitation. You've been geeky enough to discover there are exactly 899,999 days between both dates. A google search for calendar + "900000 days" eventually hit Roy Martin's article. It appears Katie's guess about only one half of one internal register being used to hold the numbers of days is correct. Well, the HP-12C might have been used within all Star Trek series time frames. Anyway, they'd better take along a 17B-II, just in case. Regards, Gerson.

Re: 12c date range Message #17 Posted by Don Shepherd on 11 Nov 2010, 9:35 a.m., in response to message #16 by Gerson W. Barbosa Thanks Gerson. Yeah, the 17bii can track all the way to Dec 31, 9999 (as does the 30b), so that should cover all the Star Trek missions! Hmm, the year 9999 raises an interesting question. Will they have a "Y10K" problem then, when all the existing computer systems allow only 4 digits for the year? OTOH, I'm sure computers as we know them won't exist by that time. :) Don Edited: 11 Nov 2010, 10:48 a.m.

Re: 12c date range Message #18 Posted by Thomas Okken on 11 Nov 2010, 1:15 p.m., in response to message #17 by Don Shepherd Quote: Hmm, the year 9999 raises an interesting question. Will they have a "Y10K" problem then, when all the existing computer systems allow only 4 digits for the year? I'm not sure about Windows, but Unix is moving toward time_t being 64 bits wide; assuming all the versions that use a 32-bit time_t have been phased out by 2038, we'll be fine for another 100 trillion years. We may need another fix sometime before the heat death of the universe, though... Then again, all the databases that store years as 4-digit numbers *will* cause Y10K problems. :-)

Re: 12c date range Message #19 Posted by Walter B on 11 Nov 2010, 3:32 p.m., in response to message #18 by Thomas Okken Quote: We may need another fix sometime before the heat death of the universe, though... AFAI have read recently (e.g. in Scientific American), the universe will eventually rather freeze out due to its accelerated expansion. A pulsing universe, though an idea I'd prefer for several reasons ;) , seems to be pretty unlikely based on the knowledge we have right now. FWIW

Re: 12c date range Message #20 Posted by Gerson W. Barbosa on 11 Nov 2010, 3:57 p.m., in response to message #19 by Walter B Heat or Freeze? I go with Frost :-) Fire and Ice by Robert Frost Some say the world will end in fire; Some say in ice. From what I've tasted of desire I hold with those who favor fire. But if it had to perish twice, I think I know enough of hate To say that for destruction ice Is also great And would suffice.

Re: 12c date range Message #21 Posted by Eric Smith on 11 Nov 2010, 10:19 p.m., in response to message #19 by Walter B "Heat death" refers to entropy reaching a maximum; because the universe is expanding it is entirely possible that it will be very cold when that happens.

Re: 12c date range Message #22 Posted by Walter B on 12 Nov 2010, 3:03 a.m., in response to message #21 by Eric Smith Cold heat :))

Re: 12c date range Message #23 Posted by Martin Pinckney on 11 Nov 2010, 10:22 p.m., in response to message #17 by Don Shepherd "Y2K" was such a big hoax. And even many professionals fell for it.

Re: 12c date range Message #24 Posted by Katie Wasserman on 11 Nov 2010, 10:47 p.m., in response to message #23 by Martin Pinckney Quote: "Y2K" was such a big hoax. And even many professionals fell for it. We're way OT here, but having spent 1999 working on zillions of needed program changes for many wall street systems, I have to take exception to this. While the Y2K boundary issue that many feared never materialized this was because of the early and active recognition of the issue and the huge amount of work that went into fixing it. -Katie Edited: 12 Nov 2010, 5:02 a.m. after one or more responses were posted

Re: 12c date range Message #25 Posted by John B. Smitherman on 11 Nov 2010, 10:56 p.m., in response to message #24 by Katie Wasserman I have to agree with Katie. I spent many hours in 1998 and 1999 testing, assessing, fixing, upgrading and replacing software. Most of the work was on vital systems but some was cosmetic. This made the changeover a non-event. John

Re: 12c date range Message #26 Posted by Thomas Okken on 12 Nov 2010, 12:08 a.m., in response to message #23 by Martin Pinckney Quote: "Y2K" was such a big hoax. And even many professionals fell for it. Yay, a populist slogan! It's a guaranteed win on the campaign trail: either there was an actual problem that was fixed thanks to timely action, but now nobody will ever know; or there wasn't a problem, and all the time and effort that was spent on it was a waste. I could mention that I spent a lot of time in 1999 helping to identify, fix, and test Y2K-related issues for a major U.S. telecom, but, you'd probably just call me a liar. Or were you actually trying to make a point? And if so, what?

Re: 12c date range Message #27 Posted by bill platt on 12 Nov 2010, 12:12 a.m., in response to message #23 by Martin Pinckney The "hoax" part was the idea, cultivated all across the "media," that it would be an unfixable Armageddon like disaster. This is how they interpret engineering problems for the masses. The media treats political problems and engineering problems exactly the same, while pretending to actually know something about the weather... But the consequences were dire, would it were that the work Katie described went undone.

Re: 12c date range Message #28 Posted by Don Shepherd on 12 Nov 2010, 2:46 a.m., in response to message #23 by Martin Pinckney I concur with Katie and John and Thomas. I worked for Computer Sciences Corporation in the late 1990's on a special Y2K team charged with identifying and fixing potential problems in client's code systems. We even developed specialized software that looked at source code and tried to identify problems automatically. And we found (and fixed) plenty of problems. Later (1998), I worked for a smaller firm that did the same thing, mostly for clients in the health care field. You'd be surprized how many automated and embedded systems there are in a large hospital. Most of those systems were OK and required no change, but many did. Interestingly, probably the most critical system we examined was US air traffic control within the FAA. I don't recall any critical problems within that system, mostly because air traffic control is largely not dependent upon dates. January 1, 2000 passed uneventfully, largely because of all the work done beforehand. But had that work not occurred, there would have been many problems.

Re: 12c date range Message #29 Posted by Martin Pinckney on 12 Nov 2010, 10:27 a.m., in response to message #23 by Martin Pinckney OK, what I meant was, all the media and cult hoopla about how the world as we know it was going to end because of this "bug." Yes, there were programming problems that had to be fixed, and thanks to Katie et al for doing so. But the idea was bandied about that somehow, because computer programs only had two digit dates, when January 1, 2000 arrived, the computers would "think" it was 1900, and all of us were not born yet, so somehow all our bank accounts would suddenly vanish. And the electric power system would fail because the power grid had not been invented in 1900... etc. etc. All nonsense. There were many books written, websites started, a whole survivalist culture developed around a bogus notion. And it was kept up right up until the last, in spite of the reprogramming that was done. That was the hoax.

Re: 12c date range Message #30 Posted by Don Shepherd on 12 Nov 2010, 5:41 p.m., in response to message #29 by Martin Pinckney Martin, I personally don't remember all of the media hoopla and world-ending predictions that you describe. That may have happened, but anyone familiar with computers and programming (most of the members of this forum, for example) would have known that this was just a relatively simple problem that needed to be assessed and fixed, and that's exactly what happened. I sure didn't stay up until midnight on 12/31/1999 to see if the earth would vanish at precisely midnight! While Y2K did provide a unique way for old COBOL and FORTRAN programmers to cash in, it was, by it's nature, a very time-sensitive endeavor, because there was NO Y2K work to be done after the event. The consulting company I worked for at that time went out of business in December 1999, and I became a teacher! Don

Re: 12c date range Message #31 Posted by Martin Pinckney on 12 Nov 2010, 9:31 p.m., in response to message #30 by Don Shepherd A couple of web pages still discussing this: Wikipedia. A good article from The University of Queensland.

Re: 12c date range Message #32 Posted by Don Shepherd on 13 Nov 2010, 7:35 a.m., in response to message #31 by Martin Pinckney Good links Martin, thanks. I learned a new acronym: TEOTWAWKI. It's interesting to speculate about what would have happened around 1/1/2000 if nothing at all had been done in advance. Of course, the world would not have ended. Computer programs would not necessarily have aborted, but many would have generated incorrect values, which would have resulted in incorrect data in electronic files, financial statements being wrong, scheduling systems being wrong, reports being wrong, and so forth, none of which would have been critical but all of which would have had to be fixed. So Y2K resulted in the problems being fixed beforehand, rather than dealt with at the time of error occurrance. It's too bad none of us will be around in the year 10,000 although, as I said, computers as we know them today won't be around then. It's interesting to imagine what will.

Re: 12c date range Message #33 Posted by Thomas Klemm on 17 Nov 2010, 12:01 a.m., in response to message #11 by Don Shepherd Quote: Does anyone have access to it? If you build nonpareil with the option has_debugger_gui=1 you will get an additional tab labeled "Debug". One of the choices in the menu is "Trace". If enabled you get 3 lines for each executed machine instruction: 03462: 0456 a=a+b w cycle 17711 P=7 q=8 carry=0 stat=...3.......... a=01200000000000 b=01200000000000 c=03060009999999 I haven't analyzed the whole program yet but this algorithm is used: if m <= 2: m = m + 12 y = y - 1 jd = int(365.25*y) - int(y/100) + int(y/400) + int(30.6001*(m+1)) + d - 478164 This maps 15-10-1582 to 100000 and 25-11-4046 to 999999. For both limits I compared the trace-output with that of the date just one day beyond the limit to find the point where they diverge: 14-10-1582 15-10-1582 1582 * 365.25 = 577825.5 577825 1582 * 365.25 = 577825.5 577825 1582 -> 15 - 15 1582 -> 15 - 15 577810 577810 15.82 / 4 = 3.955 + 3 15.82 / 4 = 3.955 + 3 577813 577813 11 * 30.6001 = 336.6011 + 336 11 * 30.6001 = 336.6011 + 336 578149 578149 14 + 14 15 + 15 578163 578164 - 478164 - 478164 99999 100000 cycle 4161 P=c q=8 carry=0 stat=...3.......... cycle 4968 P=c q=8 carry=0 stat=...3.......... a=00999990000000 b=05781630000000 c=05781630000005 a=01000000000000 b=05781640000000 c=05781640000005 03363: 1502 ? a<>0 p 03363: 1502 ? a<>0 p cycle 4162 P=c q=8 carry=0 stat=...3.......... cycle 4969 P=c q=8 carry=1 stat=...3.......... Here P=c which means it points to nibble 12 (i.e. the 2nd from left). Still I don't understand why the lower limit 100000 was chosen. Using 0 instead leads to negative numbers for dates earlier than 15-10-1582. This sets the carry-bit and is easy to detect. 25-11-4046 26-11-4046 4046 * 365.25 = 14778015.5 1477801 4046 * 365.25 = 14778015.5 1477801 4046 -> 40 - 40 4046 -> 40 - 40 1477761 1477761 40.46 / 4 = 10.115 + 10 40.46 / 4 = 10.115 + 10 1477771 1477771 12 * 30.6001 = 367.2012 + 367 12 * 30.6001 = 367.2012 + 367 1478138 1478138 25 + 25 26 + 26 1478163 1478164 - 478164 - 478164 999999 1000000 cycle 18292 P=c q=8 carry=0 stat=...3.......... cycle 4145 P=c q=8 carry=0 stat=...3.......... a=01478163000005 b=14781630000000 c=09999990000000 a=01478164000005 b=14781640000000 c=10000000000000 03325: 1376 ? c<>0 s 03325: 1376 ? c<>0 s cycle 18293 P=c q=8 carry=0 stat=...3.......... cycle 4146 P=c q=8 carry=1 stat=...3.......... Here the sign of register c is checked and thus a date outside the range will be detected. Quote: The second date is determined by internal register limitations There's enough space. All the numbers could be shifted one place to the right. I don't see the limitation. Cheers Thomas

Re: 12c date range Message #34 Posted by Don Shepherd on 17 Nov 2010, 7:27 a.m., in response to message #33 by Thomas Klemm Thomas, thanks for the analysis of the 12c code. Unless Roy Martin is still around and happens to see and respond to this thread, I guess we won't know why he said that was the limitation. Perhaps there was something else at work here that was perceived as a limitation, who knows. Don

Re: 12c date range Message #35 Posted by Thomas Klemm on 17 Nov 2010, 3:55 p.m., in response to message #34 by Don Shepherd I found this old thread: 30.6001, 25 year old hack? The same constant is used in the HP-12c so it might as well be that some old code was reused. From the HP-92 which is described in the acrticle of the Hewlett-Packard Journal or even from the HP-80 where space was much more limited.

Re: 12c date range Message #36 Posted by Katie Wasserman on 17 Nov 2010, 8:48 p.m., in response to message #35 by Thomas Klemm Somewhat disturbingly the the formula given in the appendix of the 12C manual is different from what you've uncovered. Perhaps they give the same result but why present a formula that's not actually used and claim that it is? -Katie

Re: 12c date range Message #37 Posted by Thomas Klemm on 18 Nov 2010, 3:26 a.m., in response to message #36 by Katie Wasserman What is the formula given in the manual? A typical trace of the execution of DATE consists of about 29k lines. I didn't read that line by line. Instead I was looking for some patterns, numbers mostly, and followed them while they are processed. There are situations when you realize now you're in a loop as in a multiplication or a division and you want to fast forward. Instead of scrolling down I calculated the expected result and searched for the next occurrence. So the intemediate results I've given in the previous post are like links to points of interest in the trace. Between them sometimes things happen I don't really understand. So it may well be that something slipped through. After all it's my interpretation of what's going on. The formula isn't written there as in a high level language. I was surprised to find 30.6001. That's why I googled it. I hoped to find a formula to calculate the Julian day number. It's funny that the first hit brought me back to this forum. Best regards Thomas

Re: 12c date range Message #38 Posted by Thomas Klemm on 18 Nov 2010, 4:10 a.m., in response to message #37 by Thomas Klemm Quote: What is the formula given in the manual? Okay, I guess I found that by myself. Quote: Note: Additional tests are performed to ensure that the century (but not millenium) years are not considered leap years. What about 1600 or 2400? Leap year or not? And what about 3000? BTW: I just had a look at DATE not at dDYS. Cheers Thomas

Re: 12c date range Message #39 Posted by Katie Wasserman on 18 Nov 2010, 11:04 a.m., in response to message #38 by Thomas Klemm Quote: It's funny that the first hit brought me back to this forum. Of course, who else would be concerned about something so esoteric! :) Quote: I just had a look at DATE not at dDYS That could indeed be different code, since the DATE function is also returning the DOW.

Re: 12c date range Message #40 Posted by Thomas Okken on 12 Nov 2010, 12:29 a.m., in response to message #1 by Don Shepherd I can't answer the original question, but just to add another data point: The HP-41 Time Module handles dates from October 15, 1582, until September 10, 4320 -- 999,999 days later. I've wondered about that limit, too... It's obviously not a problem, but why they chose a limit well below what the calculator *could* handle, I would be interested to know. :-)

Re: 12c date range - 17bII+ Message #41 Posted by Marcus von Cube, Germany on 12 Nov 2010, 4:34 p.m., in response to message #40 by Thomas Okken The same holds for my 17bII+. I can enter 10.151582 in DATE1, 999,999 in DAYS and I get 9.104320 as DATE2. Increasing DAYS by 1 results in an error calculating DATE2. Edit: I must have made a mistake. I can't go below October 10, 1582 but easily up to December 31, 9999 Edited: 12 Nov 2010, 4:42 p.m.

Re: 12c date range - 17bII+ Message #42 Posted by bill platt on 12 Nov 2010, 4:43 p.m., in response to message #41 by Marcus von Cube, Germany I just added 1e6 days to the Julian start date in my 27s and it worked. Sept 11, 4320. And this is 890s technology. It will take 2E6 and calc 8/8/7058 5e6 is invalid. I wonder why the 17bii+ is less than its predecessor the 27s? (problem solved. 17bii+ covers more. Entry error). OK that makes sense--that the 17bii+ has more range. Edited: 12 Nov 2010, 5:00 p.m. after one or more responses were posted

Re: 12c date range - 17bII+ Message #43 Posted by Marcus von Cube, Germany on 12 Nov 2010, 4:55 p.m., in response to message #42 by bill platt As you can see, I had to edit my post because of some stupid data entry mistake. So the 17bII+ goes from 10/15/1582 to 12/31/9999.

Re: 12c date range - 17bII+ Message #44 Posted by Mark Harman on 12 Nov 2010, 5:24 p.m., in response to message #41 by Marcus von Cube, Germany The 30b has the same range. This gives a total range of 3,074,323 days between dates in Actual mode and 3,030,196 in Cal.360 mode. Mark

[ Return to Index | Top of Index ]

Go back to the main exhibit hall