Repository navigation
fix(libkernel): report the host zone's standard offset and daylight saving amount from sceKernelGettimezone - #10499
Conversation
…aving amount from sceKernelGettimezone
sceKernelGettimezone wrote {0, 0} for every zone. A PS5 on firmware
13.40 set to US Eastern returned tz_minuteswest -300 and tz_dsttime 60:
the standard offset in minutes east of UTC, without the summer time in
effect on the run date, and the zone's daylight saving amount in
minutes. Both now come from the host zone, through the same HostZoneAt
and HostDaylightAmount the calendar conversions use.
guest_freebsd_clocks checks five TZ settings (UTC0, IST-5:30, BRT+3,
EST5EDT, CET-1CEST) and the null pointer.
harisibrar1
left a comment
harisibrar1
left a comment
There was a problem hiding this comment.
Checked against main 6c52b64, FreeBSD 11.4 sys/sys/time.h / kern_time.c, and shadPS4 23c41333 kernel/time.cpp:
- This merges cleanly. Main still writes
{0, 0}here, and the change reuses theHostZoneAt/HostDaylightAmounthelpers already on main. Reading them, the signs look right on both paths: on Windows-_get_timezoneand-_get_dstbiasgive east and a positive DST amount, and on POSIXtm_gmtoff + timezoneis the DST amount. I couldn't run the Windows path myself. - Worth stating plainly: this departs from FreeBSD's
struct timezone, which is "minutes west" plus aDST_*type (DST_USA= 1), so US Eastern would be 300/1 rather than -300/60. shadPS4 returns_timezone/60and_daylighton Windows, which also differs. So the console run is the only basis here, and it does fit main's existingConvertUtcToLocaltimeentry (seconds east). Could you attach the payload source or its output to the PR, so others can repeat it in a zone without DST or in winter? - Minor: once this lands,
gettimeofday'stzstill reports{0, 0}, while on FreeBSD both come from the same kernel globals. The PR already notes this, so it's fine as a follow-up.
Reviewed with AI assistance (Claude Code); the checks above were run locally on my machine.
|
Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
MarcZX10
left a comment
MarcZX10
left a comment
There was a problem hiding this comment.
The code and boundary tests look consistent with the measured console result and with the existing host-zone helpers. The author reports the focused Windows test and negative control; Linux and hosted build jobs did not run, and I did not rerun tests locally.
One overlap item needs an agreed order before approval: #10198 is still open, and the overlap report identifies a conflict on the same libkernel debt line this PR edits. Please coordinate with that author and declare which change lands first under Depends on (or update the other PR's checklist to establish the reverse order). #9682 is separately scoped to gettimeofday and is already called out accurately in the description.
|
Linux run (Ubuntu 26.04 container, GCC 15, glibc 2.43, CMake + Ninja, Release,
This covers the "Not run on Linux" item. |
…e-host-zone # Conflicts: # core/libs/tests/GuestFreebsdClocks.cpp
|
@MarcZX10 This PR now lists @harisibrar1 the probe and its output are in the Measurement paragraph now: a plain call on a 0x55-filled buffer, plus the same run's local-time conversions that show the zone. @Dom3005 thanks for the Linux run; the body points to it. AI-assisted: yes (Claude Code) |
|
Tested
Test suite only; no title was run. AI-assisted: yes (Claude Code) |
|
@MarcZX10 A correction to my last comment: orezraey had already proposed on #10198 (10/24) that this PR land first, and #10198 lists AI-assisted: yes (Claude Code) |
|
@MarcZX10 #10198 landed first after all (today, 15:37), so I merged AI-assisted: yes (Claude Code) |
Dismissing a stale review: the requested changes were addressed after it (new head) and the merge queue blocks on it. Please request changes again if anything is still open.
|
Checked |
What
sceKernelGettimezonewrote{0, 0}for every zone, a silent stub that the debt entry for the calendar conversions mentions ("sceKernelGettimezoneand thegettimeofdaytime zone still report no offset and no daylight saving"). It now fills both fields from the host zone, with theHostZoneAtandHostDaylightAmounthelpers the calendar conversions in the same file already use:tz_minuteswest: the standard offset in minutes east of UTC, despite its name, without the daylight saving in effect.tz_dsttime: the zone's daylight saving amount in minutes, 0 for a zone without daylight saving.0x8002000E.Measurement: PS5 on firmware 13.40 set to US Eastern, 2026-10-19, from an elfldr payload process:
sceKernelGettimezonereturned 0 withtz_minuteswest-300 andtz_dsttime60. Summer time was in effect on the run date, so -300 is the standard offset, not the current one, and 60 is the daylight saving amount, not a flag. What the console returns outside summer time, or for a zone without daylight saving, was not measured; this console is the only sample.The probe resolves
sceKernelGettimezonefromlibkernelin the payload process and calls it on a buffer filled with 0x55, the equivalent of:Its output:
sceKernelGettimezone(&tz) -> 0x00000000 minuteswest=-300 dsttime=60. In the same runsceKernelConvertUtcToLocaltimegave local minus UTC of -14400 for 2024-07-01 12:00Z and -18000 for 2024-01-15 12:00Z, with the daylight amount 3600, so the console was on US Eastern. Anyone with a payload loader can repeat it in a zone without daylight saving or in winter.The debt entry moves out of the long calendar conversion entry into one of its own, which says the values follow the host zone rather than the console's time zone setting and what was not measured. The
gettimeofdaytime zone is unchanged; #9682 touches that one.Tested
Windows 11 (build 26200), MinGW GCC (WinLibs 15.2) Release build with
BUILD_TESTING=ON, each run three times (ctest --repeat until-fail:3).mainca6e29e after docs(libkernel): record what the local time conversions write on a PS5 #10198 merged (head 02eb825; the libkernel debt conflict resolved by keeping both PRs' entries):guest_freebsd_clockspasses, and so doesmainca6e29e.guest_freebsd_clocksgets a case that setsTZand readssceKernelGettimezone:UTC0gives 0 and 0,IST-5:30330 and 0,BRT+3-180 and 0,EST5EDT-300 and 60,CET-1CEST60 and 60; and a null pointer returns0x8002000E. On Windows the expected daylight amount comes from the C runtime's_get_dstbias, as the test's existing zone cases already do, since aTZvariable does not set it.main97d3346 merged in):guest_freebsd_clockspasses.main97d3346 with only this PR'sGuestFreebsdClocks.cpp:guest_freebsd_clocksaborts on the new case.main97d3346 with its own test: passes.main39a36bb passes 3 of 3, including theTZcases, where the daylight amount comes from glibc's zone data; the control aborts as on Windows. @TechLevelZero's fleet run (Linux, validation layer on) of4db6ed763merged ontomain5b85225ef: no PR-only failures in the 1941 teststools/select_tests.pyselects, on a Ryzen 7 9700X iGPU (RDNA2), an RX 9070 XT (RDNA4), Iris Xe, lavapipe on two CPUs and an NVIDIA A800.tools/check_conventions.py --base origin/mainreports no errors; its one warning is the length of the calendar conversion debt entry, which was already over the limit before this PR shortened it.Overlap
#10198 (orezraey), which added a measured calendar conversion entry right after the debt entry this PR edits, merged first; this branch merges
mainafter it and keeps both entries. #10975 (xXPBSXx) changes the samesceKernelGettimezonebody to write{0, 0}throughGuestCopyOut_nid_no_patch, so an unusable pointer returnsEFAULT; whichever of the two lands second writes this PR's values through that copy.Checklist
main; no other open PR implements the same functions. fix(libkernel): fail gettimeofday, getitimer, setitimer and the sceKernel time getters with EFAULT on an unusable pointer #10975 changes howsceKernelGettimezonewrites its result, not what it writes (see Overlap); feat(libkernel_sys): implement settimeofday #9682 changesgettimeofday's time zone output in the same file.NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)