On 11/05/2026 15:29, Simon Glass wrote:
> The commit message says tm_year is not initialised in the MMDDhhmm
> case, but do_date() calls dm_rtc_get() into the same struct before
> mk_date(), so tm_year holds the current RTC year on entry. That is
> what makes the leap-year check work. You could rephrase to something
> like 'tm_year is not set by mk_date() in this path, so the leap-year
> check relies on the caller having pre-populated it (do_date() does,
> via dm_rtc_get())'.
Valid point. This is my new proposal:

cmd: date: validate date using rtc_month_days()

The old check accepted month 0 as well as Feb 29th in non-leap years.
With this change, both day and month 0 are rejected, and the local day limit
logic is now handled by rtc_month_days(), which correctly accounts for month
length and leap years.

In the 'MMDDhhmm' format case, tm_year is not initialized by mk_date().
The leap-year calculation in rtc_month_days() therefore depends on the value
provided by the caller, which do_date() does, via dm_rtc_get().
This is pre-existing behaviour, but is now made more explicit.

> I wonder if mk_date() could be static?
Affirm. I will add that when posting the next version.

Regards,
Alex

Reply via email to