Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Plugins
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Eric Farmer - 2009-09-29
Last edited by Michael Chicoine - 2009-10-09

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

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)

Closed by  Michael Chicoine
2009-10-09 09:46
Reason for closing:  Fixed
Additional comments about closing:  

Fixed in r23037

Nils Wallménius commented on 2009-10-03 08:57

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?

Michael Chicoine commented on 2009-10-04 22:37
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.

betonpoaltie commented on 2009-10-08 14:05

Same problem here with sansa Fuze v1
Not solved yet, but not tried <r22839 yet..

Michael Chicoine commented on 2009-10-08 15:13

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

Nils Wallménius commented on 2009-10-08 21:56

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 :)

Michael Chicoine commented on 2009-10-08 22:08

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.

Michael Chicoine commented on 2009-10-09 02:45

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.

Nils Wallménius commented on 2009-10-09 06:15

Michael, that patch looks correct to me, it was a stupid mistake after all :)
Thanks for fixing it, please commit.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing