Transition from active to passive and vice-versa happens at 12pm about avatarwallpaper HOT 5 CLOSED

The passive/active state is based on the day as reported from the system, so I'm not sure how this could come about. Sometimes the display will show the last state it was in for a few frames before switching, so perhaps that was the case?

from avatarwallpaper.

I woke up this morning and it was in the active state. First avatar was running for a while, then biking. It stayed in active state at least until the last time I checked at 11:40am. Next time I checked after 12:30pm, and it was in the passive state (watching TV). It's still in the passive state now.

I noticed this the other day, too, but I wasn't sure if I was just remembering the day's animation state (passive or active) wrong.

On Aug 11, 2012, at 1:01 PM, Tylar <[email protected]mailto:[email protected]> wrote:

The passive/active state is based on the day as reported from the system, so I'm not sure how this could come about. Sometimes the display will show the last state it was in for a few frames before switching, so perhaps that was the case?

—
Reply to this email directly or view it on GitHubhttps://github.com/7yl4r/MirrorMe-Avatar/issues/7#issuecomment-7668306.

from avatarwallpaper.

I can't reproduce this issue, but my best guess on this is that the time zone is not coming through correctly somehow. I am thinking that since we are -6 UTC, somewhere this is being interpreted as +6, causing the 12 hour shift. I'll see if there is anything I can do about it in the code.

from avatarwallpaper.

Ooops. Eastern time is -4... That makes this error even more baffling.

The shift between active and passive hinges on this one line of code:

int today = Time.getJulianDay( System.currentTimeMillis(), TimeZone.getDefault().getRawOffset() );

That value is then checked for even/oddness with if(today%2 == 0) This use seems to be correct according to the Time and TimeZone documentation.

I have also verified that System.currentTimeMillis() does return in UTC myself, since the documentation felt a little ambiguous.

...From some added debugging code it seems that TimeZone.getDefault().getRawOffset() is the problem here, since values logged from that method are not as expected. No clue why though. I'll continue trying to figure it out or find an alternative.

from avatarwallpaper.

The code has changed a lot since this bug surfaced, hopefully this bug is fixed.

from avatarwallpaper.