Rockbox

Tasklist

FS#10625 - Calendar off by a couple days, saving time increments date by 1

Attached to Project: Rockbox
Opened by Eric Farmer (databat) - Tuesday, 29 September 2009, 18:06 GMT
Last edited by Michael Chicoine (mc2739) - Friday, 09 October 2009, 09:46 GMT
Task Type Bugs
Category Plugins
Status Closed
Assigned To No-one
Operating System Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Daily Build r22850-090929 for the Sansa e200 V2

The calendar is a bit off. Today is September 29, 2009 on a Tuesday, and the Calendar shows it's on a Sunday. (two days off! And yes, I am certain it is set for the correct date and time. I checked it 8 times to make sure I wasn't seeing things.)

I have also noticed, each time you go under System, Set Time and Date, each time you make a change it increments the date by one when you save. You have to set the date to one day before the current one, then upon saving it will increment to the correct time. (I discovered this while trying to figure out why the calendar was off)
This task depends upon

Closed by  Michael Chicoine (mc2739)
Friday, 09 October 2009, 09:46 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r23037
Comment by Nils Wallménius (nls) - Saturday, 03 October 2009, 08:57 GMT
hi, could you test a build from before r22839 to see if either or both of these issues were introduced in that rev or already present?
Comment by Michael Chicoine (mc2739) - Sunday, 04 October 2009, 22:37 GMT
>I have also noticed, each time you go under System, Set Time and Date, each time you make a change it increments the date by one when you save. You have to set the date to one day before the current one, then upon saving it will increment to the correct time.

This is most likely the reason for the problems in the calendar plugin.

I have also seen this, around the time the RTC offset was adjusted so that Rockbox would show the same time as the OF. If I remember correctly, I changed the date in the OF and then returned to Rockbox and changed the date back to the correct setting (it might have been the opposite, change date in RB then correct in OF). After performing this process, I have no longer had problems with date adjustment.

I have not heard of any others Sansa AMS users who have seen this problem. I have tried unsuccessfully to recreate the problem for further debugging.
Comment by betonpoaltie (betonpoaltie) - Thursday, 08 October 2009, 14:05 GMT
Same problem here with sansa Fuze v1
Not solved yet, but not tried <r22839 yet..

Comment by Michael Chicoine (mc2739) - Thursday, 08 October 2009, 15:13 GMT
This is acting exactly as before r20697 where setting the time in Rockbox causes the OF time to revert to Sept. 24, 2007, 12:00 am. This was assumed to be because the OF starts counting from Jan 1st 1970 instead of 1980. r20697 introduced a SECS_ADJUST define to account for the different starting point. It seems that this adjustment may not be working now.

Edit: I have confirmed this did start with r22839
Comment by Nils Wallménius (nls) - Thursday, 08 October 2009, 21:56 GMT
michael, i'm a bit confused by your comments, are you now able to reproduce this on a ams sansa and can confirm it started with r22839? also has anyone tried on a pp sansa? The patch for r22839 was tested and confirmed working on a e200v1 and clip...
I did look through the changes that i made in that patch again and can not see any obvious mistakes, that does of course not mean there aren't any :)
Comment by Michael Chicoine (mc2739) - Thursday, 08 October 2009, 22:08 GMT
Nils, yes I have reproduced this on an e260v2 - the clock setting works with r22838 and fails as described above on r22839. I do not notice anything obvious either, but will look deeper into the offset for the Sansa AMS models.
Comment by Michael Chicoine (mc2739) - Friday, 09 October 2009, 02:45 GMT
Nils, after testing on e200 with r22935, I am seeing the same date increment when changing the date. Go to system -> time & date -> set time/date and just press select without changing anything, when it returns, you will see the date advance one step.

In looking at the code, at line 152, tm->tm_year = 109. This is due to adding 100 at line 97. This additional 100 has not been taken into account in the calculations on line 152.

I have attached a patch to fix rtc_as3514.c and tested on both the e200 and e200v2 for proper operation. I did not simplify the math for clarity. You can change it if it makes more sense to simplify.

I scanned through the other rtc drivers and it appears that this was the only one with this problem.
Comment by Nils Wallménius (nls) - Friday, 09 October 2009, 06:15 GMT
Michael, that patch looks correct to me, it was a stupid mistake after all :)
Thanks for fixing it, please commit.

Loading...