ActivityMonitor.History.startOfDay and time zones

Former Member over 10 years ago

My understanding is that a Moment represents a UTC timestamp, and Gregorian.info() will apply the local timezone to the Moment as part of its formatting. So far so reasonable :-)

But ActivityMonitor.History.startOfDay seems to behave rather oddly, given the above.

The activity counter rolls over at local midnight. But the startOfDay Moment seems to represent either the time midnight occurred in the UTC timezone in UTC terms, or the local midnight in local terms. (Both cases are identical.)

Therefore when Gregorian.info() applies the timezone offset it's correcting for something which has already been corrected for, and if you're in the western hemisphere, you end up with the wrong day (the previous one).

I'm correcting this here: https://github.com/simonmacmullen/activity-widget/blob/e0fd32c4a6ab669e5a43cf1c8e43946c7ba3e7c7/src/ActivityWidgetView.mc#L133 but to me this smells like a bug. Am I missing something or is this intentional? (And if it's intentional can it please be documented?)

Former Member over 10 years ago

I've added a ticket to investigate this. I think the ActivityMonitor time has already been converted to local time as you have observed. Gregorian.info is expecting a UTC time. My guess is the startOfDay should be corrected to be a UTC time and not a local time, but we will verify before making a change.

Nikeow over 9 years ago

I've added a ticket to investigate this. I think the ActivityMonitor time has already been converted to local time as you have observed. Gregorian.info is expecting a UTC time. My guess is the startOfDay should be corrected to be a UTC time and not a local time, but we will verify before making a change.

i _think_ i am also bitten by this bug.
As of right now, the ActivityHistory Days (i'm only showing the day of week) is 8 hours off. Meaning - while the watch's ActivityHistory array gets pushed to include the current day and the oldest day gets popped out of the array - It is taking 8 hours (my timezone) before the day_of_week is even changed on the watch.

I'm not sure how to proceed now given this. Should I fix (tho I am not entirely sure how yet) or should I wait and just live w/ the 8hr delay ( at least for it it's 8 hours. 8am local time the day_of_week would reflect correctly. not before.

Former Member over 9 years ago

I'm going to try to get a fix in for this as soon as possible, so I would avoid a workaround for now if possible.

jim_m_58 over 9 years ago

I'm going to try to get a fix in for this as soon as possible, so I would avoid a workaround for now if possible.

I think I reported this first on 2.70 FW for the vivoactive (it worked prior to that), and at that time, it was said that it had something to do with the unix epoch vs the garmin epoch and how there was an inconsistency in a few places.

Former Member over 9 years ago

It was originally broken because the value we were retrieving from the system was in Garmin epoch and we didn't convert it. What I didn't realize when I fixed that issue is that the value is also stored internally as local time (which I don't understand, but that is irrelevant). I've gotten a conversion to UTC added in, so the next release should finally work properly.

Nikeow over 9 years ago

Thanks Brian. As I said - I don't even know how to workaround it yet, so sooner would be better than alter, but, since it's only 8hours. I'm still OK, (as opposed to some others in time zones > 8hours. )

jim_m_58 over 9 years ago

Nikeow. YMMV, but in my timezone and on a vivoactive, I just add a 24hr duration to the Start of Day Moment, and that results in the proper day of the week and day of month. I have part of the display an odd color to remind me I have this hack in place.

Nikeow over 9 years ago

I add (or rathe minus since im at UTC +8) 8hours and while the output seems to be sane, but for some reason, the day of week don't change until 8am.

I'm not sure what is happening or what I'm doing wrong (could aso be the case)