Looking at 'main.c' it appears the RP2 RTC uses 0=Monday, 6=Sunday
Code: Select all
// Start and initialise the RTC
datetime_t t = {
.year = 2021,
.month = 1,
.day = 1,
.dotw = 4, // 0 is Monday, so 4 is Friday
.hour = 0,
.min = 0,
.sec = 0,
};
Within 'machine_rtc.c' setting the RTC calculates the weekday, which also appears to use 0=Monday, 6=Sunday -
Code: Select all
// Deliberately ignore the weekday argument and compute the proper value
t.dotw = timeutils_calc_weekday(t.year, t.month, t.day);
Reading 'RTC.datetime' simply returns 't.dotw'.
So far so good, and that means what was seen by the OP and myself was correct -
OP : (2021, 9, 12, 6, 15, 50, 5, 0) - 2021-09-12 with 6=Sunday being correct
Me : (2021, 9, 13, 0, 23, 24, 12, 0) - 2021-09-13 with 0=Monday being correct
My earlier assertion that RTC.datetime was buggy rests not on that, but whether it's what should have been seen; 'RTC.datetime' should be using 1=Monday which it does not.
That it should be 1=Monday comes from looking at 'modutime.c' which returns its 'gmtime' weekday as -
Code: Select all
mp_obj_new_int((t.dotw + 6) % 7), // convert 0=Sunday to 6=Sunday
[s]That doesn't work because 't.dotw' uses 0=Monday, not 0=Sunday[/s]
Sort of, but it's 1=Monday, 0=Sunday - See later posts
The problem is we have six things which could use different enumerations -
What's held in a physical RTC chip if there is one
What's held in 'datetime_t'
What's held in 'timeutils_struct_time_t' - 0=Monday, 6=Sunday (according to shared code)
What's returned by timeutils_calc_weekday - 0=Monday, 6=Sunday (according to shared code)
What's set and read by 'RTC.datetime'
What's set and read by 'time.gtime' - 0=Monday, 6=Sunday (according to Python docs)
The issue does appears to come down to 'RTC.datetime' -
It should be 1=Monday according to
https://docs.micropython.org/en/latest/ ... e.RTC.html
It should be 1=Monday, 7=Sunday according to
https://docs.micropython.org/en/latest/ ... b.RTC.html
It is 1=Monday on a PyBoard
It is treated as 1=Monday when converting to 'time.gtime'
[s]It is 0=Monday, 6=Sunday for RP2040[/s]
It is 1=Monday, 0=Sunday for RP2040
For 'RTC.datetime' on the RP2 to be consistent with that of the PyBoard and documentation, the values read and returned need to be adjusted with respect to what is stored in 'datetime_t'. Then every thing should just work. The fixes should probably be -
Reading 'RTC.datetime'' -
Code: Select all
// Convert calc 0=Monday, 6=Sunday to RTC.datetime 1=Monday, 7=Sunday
mp_obj_new_int(timeutils_calc_weekday(t.year, t.month, t.day) + 1),
Setting 'RTC.datetime' -
Updated - see later posts
Code: Select all
// Convert calc 0=Monday, 6=Sunday to datetime_t 1=Monday, 0=Sunday
t.dotw = (timeutils_calc_weekday(t.year, t.month, t.day) + 1) % 7;
Reading 'time.gmtime' / 'time.localtime' -
Code: Select all
// Convert calc 0=Monday, 6=Sunday to time.gmtime 0=Monday, 6=Sunday
mp_obj_new_int(timeutils_calc_weekday(t.year, t.month, t.day)),
Setting 'time.gmtime' / 'time.localtime' -
Code: Select all
// Convert calc 0=Monday, 6=Sunday to timeutils_struct_time_t 0=Monday, 6=Sunday
tuple[6] = mp_obj_new_int(timeutils_calc_weekday(tm.tm_year, tm.tm_mon, tm.tm_mday)),
'time.mktime' might need a fix but is probably correct.