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

[Daniel Tang <danielzgtg.opensource@gmail.com>]

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