Skip to contentSkip to conversation

Conflict between 1-indexed kernel struct rtc_time and 0-indexed userspace struct tm

DISCUSSION Daniel Tang 1 participant 1 message Aug 25, 2025 Real time clock (RTC)

lore
Share & tools
lore
#0 lore raw

Hello,

The difference seems undocumented and ignored by userspace. At https://
github.com/util-linux/util-linux/issues/3707 , we discussed the mismatch. My kernel module's assertion that a rtc_time64_to_tm(rtc_tm_to_time64(tm), &tm_check) will result in a bit-identical struct failed at tm_yday.

Userspace https://man7.org/linux/man-pages/man3/tm.3type.html documents a 0-
indexed int tm_yday; /* Day of the year [0, 365] (Jan/01 = 0) */
The kernel struct rtc_time is uncommented, but https://github.com/torvalds/
linux/blob/b6add54ba61890450fa54fd9327d10fdfd653439/drivers/rtc/lib.c#L136 intentionally adds 1 to make it 1-indexed, and this appears to have been consistent through git history. rtc-asm9260.c and rtc-lpc24xx.c read from tm_yday before writing to hardware, but it tm_yday may have been corrected by an overwrite by other parts of the rtc core. My kernel module validates tm_yday but doesn't use it, whereas it may be unknown whether other modules are expecting a 1-indexed or 0-indexed value.

I was about to suggest that userspace perform tm_year++ before the ioctl, but then https://github.com/systemd/systemd/issues/

Quoted 2 lines · 38715#issuecomment-3221685983 said:

At least, rtc(4) states about struct rtc_time as

Quoted 1 line

The fields in this structure have the same meaning and ranges as for the tm

structure described in gmtime(3).

Quoted 1 line

I guess this is a kernel driver or firmware issue if it does not work.

What should be done to make the 0-indexing/1-indexing of tm_yday consistent between kernelspace and userspace?

Sincerely,
daniel . z . tg