12c date range


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.


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


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.



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.


Thanks for the link, Thomas. Great stuff.

will the world end then?

It looks like Dr. Kahan wondered about that 4046 date too!


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.



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.


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)


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.



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.


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.


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."



So the Mayan calendar has nothing to do with it? :-)


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.


Thanks Gerson, you 'da man. And thanks to Roy Martin for enlightening us 33 years later!



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.




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.



Edited: 11 Nov 2010, 10:48 a.m.


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. :-)


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.



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.


"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.


Cold heat :))


"Y2K" was such a big hoax. And even many professionals fell for it.


"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.


Edited: 12 Nov 2010, 5:02 a.m. after one or more responses were posted


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.



"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?


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.


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.


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.


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!



A couple of web pages still discussing this:


A good article from The University of Queensland.


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.


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.

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.




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.



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.


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?



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



What is the formula given in the manual?

Okay, I guess I found that by myself.



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.




It's funny that the first hit brought me back to this forum.

Of course, who else would be concerned about something so esoteric! :)

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.


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. :-)


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.


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


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.


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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Prime: how to detect date format giancarlo 1 690 12-02-2013, 11:21 AM
Last Post: Michael de Estrada
  Date/time formats R. Pienne 4 1,064 11-01-2013, 12:43 PM
Last Post: Marcus von Cube, Germany
  How to set the Date.Time etc on a WP34S Harold A Climer 4 989 10-29-2013, 09:32 PM
Last Post: FORTIN Pascal
  Date/time programs for the HP 35s R. Pienne 0 505 10-03-2013, 02:37 PM
Last Post: R. Pienne
  Date & Time disappear on WP 34S René Franquinet 16 2,402 12-10-2012, 08:24 AM
Last Post: Walter B
  A little OT: Blank date fields in 200LX database Dave Britten 1 627 07-12-2012, 06:11 PM
Last Post: Dave Britten
  HP SMB 15C LE ship date Scott Newell 9 1,121 12-17-2011, 11:25 PM
Last Post: Scott Newell
  38E/C, 12C, 12CP date arithmetic bug Katie Wasserman 26 2,431 10-19-2011, 08:57 PM
Last Post: Miguel Toro
  [WP34S] [Manual] Date - Day functions E.Lub_EU 2 527 09-26-2011, 05:04 PM
Last Post: E.Lub_EU
  HP 12C, 12C Platinum & 15C iOS App Walter Lam 2 620 06-02-2011, 01:25 PM
Last Post: Andrés C. Rodríguez (Argentina)

Forum Jump: