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/ 38715#issuecomment-3221685983 said: >At least, rtc(4) states about struct rtc_time as >>The fields in this structure have the same meaning and ranges as for the tm structure described in gmtime(3). >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
