Files
AnyPS5/docs/dev
ntamas94andClaude Opus 5.5 3cf419d4ea fix(libSceRtc): handle out-of-range time values as the PS4 does
Measured on a PS4 (firmware 10.71) with an OpenOrbis homebrew that loads a
probe PRX calling libSceRtc; every output starts as a sentinel, so stores
and their width are visible.

- sceRtcSetTime_t takes the low 32 bits of its argument as unsigned seconds
  and returns 0 for every value: -1 is 2106-02-07 06:28:15, 2^32 + 1 is
  1970-01-01 00:00:01 and -2^31 is 2038-01-19 03:14:08. sceRtcGetTime_t
  stays 64-bit (2106-02-07 06:28:16 is 2^32).
- sceRtcGetTime_t before 1970 and sceRtcGetWin32FileTime before 1601 store
  0 and return 0x80B50008. Field validation still comes first and leaves
  the output unchanged (1969-13-01 returns 0x80B50009).
- sceRtcSetTick and sceRtcSetWin32FileTime have no upper limit: the tick
  after 9999-12-31 23:59:59.999999 is 10000-01-01 and the file time
  2^64 - 1 is 60056-05-28 05:36:10.955161. sceRtcGetDayOfWeek accepts
  years past 9999 (10000-01-01 is 6).
- sceRtcFormatRFC3339 returns 0x80B50008 when the zone-shifted tick is
  outside years 1 to 9999. sceRtcFormatRFC2822 returns 0x80B50003 when it
  is negative as a signed value and 0x80B50008 when it is past 9999.

The PS5-measured cases of GuestRtc.cpp that the probe repeated (RFC 3339
and RFC 2822 parsing, named and military zones, DOS time, TickAdd) give the
same results on the PS4. The three expectations changed here (SetTick past
9999, SetTime_t(-1), RFC 2822 at the limit with +1 minute) came from
commits that cite no measurement. Not yet confirmed on PS5.

Written with AI assistance.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-22 15:51:03 +02:00
..