38E/C, 12C, 12CP date arithmetic bug - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: 38E/C, 12C, 12CP date arithmetic bug (/thread-202062.html) 38E/C, 12C, 12CP date arithmetic bug - Katie Wasserman - 10-19-2011 A while back a date arithmetic bug was found during beta testing that affects all the 12C, 12CP, 38E/C and 12C clone calculators ever made. It's been unreported here (or anywhere else as far as I know), it's really obscure and was apparently fixed in the Pioneer series and after. If you're not aware of this, the 38E/C and the 12C/CP calculators compute both 365 day calendar and 360 day calendar date differences in the X and Y registers respectively. If you take a forward date difference to February 28 both values (365/360) are correct. If you take a reverse date difference the 360 day value is wrong. For example: 12/31/2007 to 02/28/2008 returns X=59, Y=58; while 02/28/2008 to 12/31/2007 returns X=-59, Y=-57 and that -57 is wrong. Pretty clearly backwards in time should be the same number of days as forwards in time. While this is extremely unlikely to ever occur during normal usage, it's useful as a calculator forensic. You'll find that the 12C/12CP clone calculators -- the Aurora FN1000, Compucessory CCS 28956 and Victor V12 -- have the same bug. Prior to the 38E/C, the 92 offered 365/360 date arithmetic, but that gives different answers using 360-day calculations. -Katie Edited to correct 3/31/2008 to 03/01/2008, but that was the wrong date too, the correct date for the example is 02/28/2008. Edited: 19 Oct 2011, 10:05 p.m. after one or more responses were posted Re: 38E/C, 12C, 12CP date arithmetic bug - bill platt - 10-19-2011 Hi Katie: Interesting! I think this should go in an article entitled "calculator forensics" or something :-) Re: 38E/C, 12C, 12CP date arithmetic bug - Gerson W. Barbosa - 10-19-2011 Quote: You'll find that the 12C/12CP clone calculators -- the Aurora FN1000, Compucessory CCS 28956 and Victor V12 -- have the same bug. This means they all did an excellent reverse-engineering work :-) Gerson. Re: 38E/C, 12C, 12CP date arithmetic bug - Thomas Radtke - 10-19-2011 Proof of reliability! :-D Just wanted to try it on my 18C/19B calculators, but batteries are empty and already started leaking. Last time I checked was one week ago, and no power warning came up :-/. Re: 38E/C, 12C, 12CP date arithmetic bug - Marcus von Cube, Germany - 10-19-2011 Quote: For example: 12/31/2007 to 03/31/2008 returns X=59, Y=58; Are you sure these are correct? For me, this looks like e three month difference which should be around 90 days in any case. (90 for 360 mode, 91 for 365 mode: 31 (Jan) + 29 (Feb) + 31; if the algorithm excludes the beginning and end dates 1 less for each: 89 and 90.) Re: 38E/C, 12C, 12CP date arithmetic bug - Kerem Kapkin (Silicon Valley, CA) - 10-19-2011 Hi Katie: If I recall correctly, there are 12C Models with ABA and ABC part numbers. ABA is what widely used in the US, ABC (I may be incorrect) for Canada, UK, Brazil, etc. I think this difference was due to the differences in some financial algorithms used by these regions. Curious if you would get the same date answer from ABA vs ABC. May be the clones were reverse engineered after ABC instead of ABA model. Do you have more insight on the differences between ABA and ABC? Thanks, Kerem Re: 38E/C, 12C, 12CP date arithmetic bug - Gerson W. Barbosa - 10-19-2011 The HP-17BII ROM on Emu42 returns 91 and -91, so you might get the same results on your HP-18C and HP-19B. BTW, I have to check the batteries in my physical calculators. So far I have lost one HP-48S and one HP-49G due to battery leakage. Edited: 19 Oct 2011, 1:19 p.m. Re: 38E/C, 12C, 12CP date arithmetic bug - Katie Wasserman - 10-19-2011 My typo, should have been 03/01/2008 not 03/31/2008. Edited: 19 Oct 2011, 1:27 p.m. Re: 38E/C, 12C, 12CP date arithmetic bug - Katie Wasserman - 10-19-2011 I have no idea what the ABA vs ABC distinction is for sure, but I remember something about Canadian mortgage calculations being done differently than in the US, perhaps that's the only difference. I don't have an ABC version, it would be interesting to check for this date calculation bug. Re: 38E/C, 12C, 12CP date arithmetic bug - M. Joury - 10-19-2011 Hi Katie, I must be missing something. I have tried to reproduce this on 7 different HP12C/12CP models and so far have been unable to do so. What am I missing? My procedure: ```12.312007 ENTER^ 3.312008 deltaDYS: 91 & 90 3.312008 ENTER^ 12.312007 deltaDYS: -91 & -90 ``` Am I doing this correctly? ```Units tried: 2 * original 12C 1 * original 12CP 2 * intermediate 12CP (single 2032 cell) 1 * new 12CP 1 * 12C+ ``` Thanks, -Marwan Re: 38E/C, 12C, 12CP date arithmetic bug - Kerem Kapkin (Silicon Valley, CA) - 10-19-2011 Thanks for your response. I recently checked on HP's site and can't find any details on the differences between the two 12C models except ABC is ~\$30 more expensive then ABA (long time ago I recall reading some place about the difference in algorithm, wonder what other differences are there): Re: 38E/C, 12C, 12CP date arithmetic bug - M. Joury - 10-19-2011 Further weirdness: Original 12C & new 12CP ```12.312007 ENTER^ 3.012008 deltaDYS result: 61 / 61 3.012008 ENTER^ 12.312007 deltaDYS result: -61 / -60 ``` Obviously wrong but not what Katie is seeing. Cheers, -Marwan Edited: 19 Oct 2011, 2:17 p.m. Re: 38E/C, 12C, 12CP date arithmetic bug - Kerem Kapkin (Silicon Valley, CA) - 10-19-2011 Marwan: I got the same answer you reported, 12CP 25th AE (1 battery) Kerem Edited: 19 Oct 2011, 1:53 p.m. Re: 38E/C, 12C, 12CP date arithmetic bug - BruceH - 10-19-2011 Can someone else please check the 30B? I'm seeing 61 days in both actual and 360 mode for 12.31.2007 to 1.3.2008, likewise -61 for both going backwards. Secondly, why is Marwan seeing 61/60 days but Katie seeing 59/58 both on the 12C? PS: Wolfram Alpha thinks it is 61 days so I'm surprised this error hasn't been spotted sooner. Edited: 19 Oct 2011, 2:38 p.m. Re: 38E/C, 12C, 12CP date arithmetic bug - tony (nz) - 10-19-2011 Hi Katie that's really because the 30/360 formula (p209 in 12C manual) is asymmetric by definition and assumes the second date is after the first. Even going just one day forward from any 31st to the first will give one but going back a zero on 30/360. eg in MDY 12.312007 to 1.012008 gives 1,1 but backwards -1,0. Cheers Tony (corrected my spelling of asymmetric after reading Katie's reply) Edited: 19 Oct 2011, 9:34 p.m. after one or more responses were posted Re: 38E/C, 12C, 12CP date arithmetic bug - Michael de Estrada - 10-19-2011 Hi Marwan, I just received a new Victor V12 today, and I get exactly the same results that you do as well. Michael Re: 38E/C, 12C, 12CP date arithmetic bug - M. Joury - 10-19-2011 Yes. See here for more info on financial date calculations. It might explain some things. Cheers, -Marwan Re: 38E/C, 12C, 12CP date arithmetic bug - Marcus von Cube, Germany - 10-19-2011 Katie made a mistake. She was meaning 03/01, not 03/31. See her answer to my post above in this thread. Re: 38E/C, 12C, 12CP date arithmetic bug - M. Joury - 10-19-2011 Yes. But see my tests below with the correct dates. They still don't match Katie's results. Also see my reference to an explanation of financial date calculations (later post this thread). This may explain what is going on though I did not try to go through it in detail. Cheers, -Marwan Re: 38E/C, 12C, 12CP date arithmetic bug - Kiyoshi Akima - 10-19-2011 I don't have my 30b handy but do have a 20b. ```12.312007 <-> 3.012008 : 61 / 722941 3.012008 <-> 12.312007 : -61 / -722941 ``` The calculator seems to have a problem with the 31st day of a 30-day month. So let's back off a day... ```12.302007 <-> 3.012008 : 62 / 61 3.012008 <-> 12.302007 : -62 / -61 ``` (edited for format) Edited: 19 Oct 2011, 5:06 p.m. Re: 38E/C, 12C, 12CP date arithmetic bug - M. Joury - 10-19-2011 I looked at this on the 17bii, 17bii+ Silver, 19bii, and the HP200LX Calculator application and noticed that there were 3 results offered on each of these machines. Results below were identical on all the above platforms. ```Days = Actual number of days 360D = 360 days 365D = 365 days ``` For the dates given by Katie the 17bii returns the following: ```12.312007 DATE1 3.012008 DATE2 Results DAYS: ACTUAL DAYS = 61 360D: 360 DAYS = 61 365D: 365 DAYS = 60 Calculation reversed... 3.012008 DATE1 12.312007 DATE2 DAYS: ACTUAL DAYS = -61 360D: 360 DAYS = -61 365D: 365 DAYS = -60 ``` Interesting results and maybe explained by this. But I really have not taken the time to study it. Cheers, -Marwan Re: 38E/C, 12C, 12CP date arithmetic bug - Katie Wasserman - 10-19-2011 Sorry all. I screwed this up trying to do it from memory. Now that I've got a 12C in my hands the correct test is: 12/31/2007 to 2/28/2008 vs 2/28/2008 to 12/31/2007. I've edited the start of this thread to correct the dates. -Katie Re: 38E/C, 12C, 12CP date arithmetic bug - Katie Wasserman - 10-19-2011 I agree that HP's formula is asymmetric, which is probably why the clones have this bug too. To compute this correctly you need to recognize the date order is reverse and swap the arguments before using the formula, then sign adjust after you get the result. Re: 38E/C, 12C, 12CP date arithmetic bug - Michael de Estrada - 10-19-2011 Just rechecked it with my new Victor V12, and like you stated above, it has the same bug. Re: 38E/C, 12C, 12CP date arithmetic bug - Gerson W. Barbosa - 10-19-2011 Can the ROMs in the clones (in the alternative devices, I mean) be easily exctracted? This would be interesting. Re: 38E/C, 12C, 12CP date arithmetic bug - Kerem Kapkin (Silicon Valley, CA) - 10-19-2011 Same results using a HP-12Cp 25th AE 12.312007 <-> 3.012008 : 61 / 61 3.012008 <-> 12.312007 : -61 / -60 12.302007 <-> 3.012008 : 62 / 61 3.012008 <-> 12.302007 : -62 / -61 Edited: 19 Oct 2011, 8:33 p.m. Re: 38E/C, 12C, 12CP date arithmetic bug - Miguel Toro - 10-19-2011 Well, it seems that the bug is in the formula from the manual, so, I do not know if call it a bug, since what is implemented if what is documented :-) ```30/360 Day Basis DAYS = f(DT2) - f(DT1) f(DT) = 360 (yyyy) + 30mm + z for f(DT1) if dd1 = 31 then z = 30 if dd1 <> 31 then z = dd1 for f(DT2) (1)if dd2 = 31 and dd1 = 30 or 31 then z = 30 (2)if dd2 = 31 and dd1 < 30 then z = dd2 (3)if dd2 < 31 then z = dd2 f(DT2) = 722,880 + 31 (2) = 722,911 f(DT1) = 722,940 + 28 = 722,968 Days = -57 ``` page 252 from the User's guide Edited: 19 Oct 2011, 9:07 p.m.