When does the Y2K38 bug happen to the HP Prime?

[TheLastMillennial]

I recently forced the Y2K38 bug to happen to my original iPad and my iPad 3, it was quite an experience. Since (to the best of my knowledge) the Prime has a 32 bit CPU I was expecting it to be effected by the Y2K38 bug, but it wasn't... In fact I was able to go all the way to 2099 before HP wouldn't let me manually input the year (I had to use the calendar view). If I went any farther than 2099 with the manual year input, it would roll back to some other year. I was wondering, why doesn't the Prime get effected by the Y2K38 bug and when is its Y2K38 bug?
EDIT: I tried this on the emulator, and I was able to go all the way to the year 9999. When it rolled over to 10,000 well... I'll let this GIF explain it.

Now my question again: why does this happen on the emulator but wont happen on the physical calculator?

[cyrille de brébisson]

Hello,

Because the emulator and physical calculator do NOT handle RTC in the same way.

The emulators ask the underlying OS for the current time/date and will store a delta in second to "convert" the "real" (as in OS reported time/Date) to the "calculator" time/date as set by the user using the calendar or the Time/Date functions.

This is a 32 bit signed number and should allow a +/-68 year compared with the "real" time/date.


The calculator itself (physical unit) uses the CPU RTC. The G1 RTC and G2 RTC do NOT work in the same way. The G1 RTC counts in hour, minutes, seconds, days, months and year (with 2 digits for the year). It should therefore be limited to the 2000/2099 range (this is if my memory serves me well).

The G2 RTC is a 47 bit counter with 32768 'ticks' per seconds. This means that there is 32 bits for the seconds, or ~130 years of clock. on the G2, I choose jan 1 2000 as "start of time". This should allow the RTC to work up to ~2130.

Normally, the user SetDate function should limit you to the 2000 to 2100 range.
Nice trick trying to use the calendar to change it!

Cyrille

[TheLastMillennial]

Thanks for that information! It gave me an idea, since the date starts at 2000, what happens if I go backwards? That's how I found a better way to find the roll over time, if you change the date to Dec 31 1999, it rolls over to 2136! After some trial and error, I found the exact time that the bug occurs:

06:28:15 AM
02/07/2136
(Feb 7 2136)


As you can see, instead of rolling over to the year 2000, the clock just stops and refuses to count any farther. Nothing else was effected though, it can still do operations, the TICKS command still works properly, I couldn't find any broken programs or apps.

If you want to try this, you may need to set the time a few minutes earlier, sometimes it bugs out and rolls over the time if you set it exactly at the bugged date.