is StartODay still not corrected?

var hist = ActivityMonitor.getHistory();

for (var k = hist.size() - 2; k >= 0; k--) {
var S1 = Time.Gregorian.info(hist[k].startOfDay,Time.FORMAT_MEDIUM);
var mydateStr1 = Lang.format("$1$ $2$ $3$ $4$ $5$ $6$", [S1.day_of_week.substring(0,3), S1.month, S1.day, S1.hour, S1.min, S1.sec]);
Sys.print(k + "[" + hist.size() + "]" + ": " + hist[k].steps + " " + mydateStr1 + " |||" );

var delta2 = new Time.Duration(+Sys.getClockTime().timeZoneOffset);
var S2 = Time.Gregorian.info(hist[k].startOfDay.add(delta2),Time.FORMAT_MEDIUM);
var mydateStr2 = Lang.format("$1$ $2$ $3$ $4$ $5$ $6$", [S2.day_of_week.substring(0,3), S2.month, S2.day, S2.hour, S2.min, S2.sec]);
Sys.print(k + "[" + hist.size() + "]" + ": " + hist[k].steps + " " + mydateStr2 + " |||" );

var startOfDay1 = Time.today().add(new Time.Duration(-86400 * k));
var myinfo = Time.Gregorian.info(startOfDay1,Time.FORMAT_MEDIUM);
var mydateStr = Lang.format("$1$ $2$ $3$ $4$ $5$ $6$", [myinfo.day_of_week.substring(0,3), myinfo.month, myinfo.day, myinfo.hour, myinfo.min, myinfo.sec]);
Sys.println(k + "[" + hist.size() + "]" + ": " + hist[k].steps + " " + mydateStr);
dc.setColor(Graphics.COLOR_BLACK, Graphics.COLOR_TRANSPARENT);


}



Results in this. I'm at +8hr timezone.

5[7]: 666 Fri Jun 26 16 0 0 ||| 5[7]: 666 Sat Jun 27 0 0 0 |||5[7]: 666 Sat Jun 27 8 0 0
4[7]: 555 Sat Jun 27 16 0 0 ||| 4[7]: 555 Sun Jun 28 0 0 0 |||4[7]: 555 Sun Jun 28 8 0 0
3[7]: 444 Sun Jun 28 16 0 0 ||| 3[7]: 444 Mon Jun 29 0 0 0 |||3[7]: 444 Mon Jun 29 8 0 0
2[7]: 333 Mon Jun 29 16 0 0 ||| 2[7]: 333 Tue Jun 30 0 0 0 |||2[7]: 333 Tue Jun 30 8 0 0
1[7]: 222 Tue Jun 30 16 0 0 ||| 1[7]: 222 Wed Jul 1 0 0 0 |||1[7]: 222 Wed Jul 1 8 0 0
0[7]: 111 Wed Jul 1 16 0 0 ||| 0[7]: 111 Thu Jul 2 0 0 0 |||0[7]: 111 Thu Jul 2 8 0 0


some of the code from the above is not correct, I am unsure of which is supposed to be the correct one.
StartOfDay is supposed to be fixed in the latest SDK rev, but which is it normalised to? I tot it was supposed to be midnight?


http://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/ActivityMonitor/History.html#startOfDay-instance_method
  • http://www.timeanddate.com/time/zone/malaysia/kuala-lumpur

    If I were a betting man, I think it's NOT normalised to UTC Midnight?
  • What version of CIQ is in the firmware in the device. I was able to take my hack out to correct for this when the va was updated to FW 3.00 (CIQ 1.1.2 VM) Before that (with the CIQ 1.1.1 VM) is was still broken, even with the CIQ SDK 1.1.2.

    On the VA, the CIQ version displays under settings>system>about, and my guess is that it's fixed in some device FW but not all...

    Here is exactly what I do to get the day of the week: (it's this simple to use local time...)
    then = activityHistory.startOfDay;
    today = Calendar.info(then, Time.FORMAT_MEDIUM);
    timestamp=today.day_of_week;
    [/code]

    And "today.day" is also correct...
  • Here's what I see (in the simulator) with the code I posted above. I'm in US MST (-7), and it's 6:33 am local time on 7/3

    ts=Thurs 2 07:00
    ts=Wed 1 07:00
    ts=Tue 30 07:00
    ts=Mon 29 07:00
    ts=Sun 28 07:00
    ts=Sat 27 07:00
    ts=Fri 26 07:00


    The hour isn't local time for "midnight", but the date/dow is correct, and I've not seen (or maybe not noticed) any problem after 5pm local time on the vivoactive, when the date changes at offset 0.

    On the va (3.00 CIQ 1.1.2) This is what I see:

    ts=Thur 2 00:00
    ts=Wed 1 00:00
    ts=Tue 30 00:00
    ts=Mon 29 00:00
    ts=Sun 28 00:00
    ts=Sat 27 00:00
    ts=Fri 26 00:00


    And here the hr is correct for local time
  • Running the code

    var delta2 = new Time.Duration(+Sys.getClockTime().timeZoneOffset);
    var S2 = Time.Gregorian.info(hist[k].startOfDay.add(delta2),Time.FORMAT_MEDIUM);
    var mydateStr2 = Lang.format("$1$ $2$ $3$ $4$ $5$ $6$", [S2.day_of_week.substring(0,3), S2.month, S2.day, S2.hour, S2.min, S2.sec]);
    Sys.print(k + "[" + hist.size() + "]" + ": " + hist[k].steps + " " + mydateStr2 + " |||" );


    gets this result which is not correct on the Actual Hardware
    5[7]: 17798 Sat Jun 27 8 0 0 |||
    4[7]: 22435 Sun Jun 28 8 0 0 |||
    3[7]: 43021 Mon Jun 29 8 0 0 |||
    2[7]: 14760 Tue Jun 30 8 0 0 |||
    1[7]: 11059 Wed Jul 1 8 0 0 |||
    0[7]: 8118 Thu Jul 2 8 0 0 |||



    From the simultor
    5[7]: 666 Sat Jun 27 0 0 0 |||
    4[7]: 555 Sun Jun 28 0 0 0 |||
    3[7]: 444 Mon Jun 29 0 0 0 ||
    2[7]: 333 Tue Jun 30 0 0 0 ||
    1[7]: 222 Wed Jul 1 0 0 0 ||
    0[7]: 111 Thu Jul 2 0 0 0 |||


    this clearly looks like a bug to me. Need the CIQ people to comment on it. Looks like it back to hacking it to to midnight.
  • W/o correcting it to add the timezone offset, it looks like the watch does it itself.
    5[7]: 17798 Sat Jun 27 0 0 0 |||
    4[7]: 22435 Sun Jun 28 0 0 0 |||
    3[7]: 43021 Mon Jun 29 0 0 0 |||
    2[7]: 14760 Tue Jun 30 0 0 0 |||
    1[7]: 11059 Wed Jul 1 0 0 0 |||
    0[7]: 8118 Thu Jul 2 0 0 0 |||


    this is using the below code
    var S1 = Time.Gregorian.info(hist[k].startOfDay,Time.FORMAT_MEDIUM);
    var mydateStr1 = Lang.format("$1$ $2$ $3$ $4$ $5$ $6$", [S1.day_of_week.substring(0,3), S1.month, S1.day, S1.hour, S1.min, S1.sec]);
    Sys.print(k + "[" + hist.size() + "]" + ": " + hist[k].steps + " " + mydateStr1 + " |||" );
  • Without any adjustments, looks like we are both seeing it correct on the device, but off (at least hours) in the simulator.

    As simulating this data is new in 1.1.2, could it just be an error in how the simulated data is built? (in 1.1.1, I was off a day on the real device, and never bothered looking at hours)
  • Again - these needs the CIQ guys to comment on it. I won't know but if I were a betting man, I bet that this is a Sim Bug.
  • NIKEOW. As you and I both see it working properly in a FW version with a CIQ VM of 1.1.2 or greater (different devices), but see an error in the simulator (where having history in the simulator was just added in 1.1.2), I really think it's safe to say, there is a simulator bug! :)

    What you might be seeing are people that have FW that still has the CIQ 1.1.1 VM (or earlier), that doesn't fix the bug and are complaining.

    This is a good case where a CIQ "thing" should be able to check the devices FW/CIQ level.....
  • Ya.. that would resolve some issues w/ users not being either up to date or have min requirement before being able to install the app

    anyways.. I'm bummed.. the thought of having to rewrite my CIQ app (the objectstore thread) is really ruininig my day.
    and it's the AM and I can't go to sleep again to "sleep on it"

    Bah Humbug!!