• Replies 5 replies
  • Subscribers 19 subscribers
  • Views 308 views
  • Users 0 members are here
Options
Related

Possible startOfDay issue on simulator

Shent-Aurkhan (SHN)
over 1 year ago

hi everyone,

It seems on my side, I have an issue with startOfDay in simulator (I haven't tested it yet on real device)

with this simple loop:

var H= ActM.getHistory();
if(H==null||H.size()==0){return;}
for(var i =0;i<H.size();i++){Sys.println(i+":"+H[i].startOfDay.value());}
I get:
0:1699597381
1:1699597382
2:1699597383
3:1699597384
4:1699597385
5:1699597386
6:1699597387
it seems only 1 second is added instead of 84600.
Does it happen also to you?
If es, please let me know so that I can post it into Bug report section.
Have a great day.

Top Replies

All Replies

  • 5 days ago

    Experiencing a similar issue. Have you found a solution?

  • 5 days ago in reply to flocsy🤠
    flocsy🤠 said:
    Had similar issues last week: https://forums.garmin.com/developer/connect-iq/f/discussion/411398/time-today-timezone-vs-simulator-timezone

    ????

    1) the other thread is about Time.today(), and I don't actually see any "issues" there, just questions about how it works. After all is said and done I don't see anything wrong with Time.today(), unless there's something you didn't post in that thread

    - I don't count "Time.today() doesn't return a LocalMoment" as an issue - as explained in the thread, Time.today() predates LocalMoment by a very long time, and by the same logic one could ask why Time.now() doesn't return a LocalMoment. A more generic issue / feature request might ask why any given Moment can't be converted to a LocalMoment (without knowing the exact coordinates of the current location). Why should Time.today() be special in that regard?

    iow, if anything, I would ask for Moment.toLocalMoment to be implemented, as opposed to making a special case for Time.today.

    - I also don't count being unable to independently change the timezone of the simulator as an issue, since you can just change the timezone of the OS the simulator is running on.

    If you really thought either of those things were real bugs, you would've opened bug reports.

    btw LocalMoment represents a point in time for a *given* location, not necessarily the *current* location. With this in mind, it doesn't really make sense to expect Time.today to return a LocalMoment, unless you specify that the LocalMoment in question is for the current location or the geographical area corresponding to the current time zone. But again, this could be a generic feature for Moment in general, not just Time.today

    2) this is about values in ActivityMonitor.History.startOfDay not making any sense in the simulator. The (2-year old) example in OP shows 7 successive history entries with startOfDay only 1 second apart (instead of being at least 1 day apart)

    3) this thread is about fake simulated data. (Even if the values made sense, they would still be fake.)

    4) the other thread is about a function that returns a real value (not fake data), even though it's in the simulator. (The concept of "midnight / start of day" for today still makes sense in the simulator, as the simulator runs on a PC with a clock.)

    Even if the other thread did point to an issue, I don't see how it's related to this thread, except that both of them are about time and the concept of "start of day", in the simulator. (But the other thread is about the actual start of day for today, while this is about the start of day for simulated fake data.)

  • 5 days ago in reply to RunnerMate
    RunnerMate said:
    Experiencing a similar issue. Have you found a solution?

    Yeah I see the same thing as OP.

    If I run similar code as OP in the sim on macOS, with the latest SDK, I get:

    0:1747762698 (exactly 4 hours from when the sim started - ~17:38 in UTC, 13:38 in local time zone)
    1:1747762699 (4 hours and 1 second from when the sim started)
    2:1747762700 ...
    3:1747762701
    4:1747762702
    5:1747762703
    6:1747762704

    (Note that my current time zone is UTC-4)

    None of that really makes any sense ofc.

    I would expect each timestamp to refer to midnight (local time) on different days (probably successive days). I haven't tried it on a real device, but that's what I would expect to see. I assume it works on a real device, otherwise every app that uses ActivityMonitor would be broken.

    Indeed, 10 years ago there was a different bug with ActivityMonitor.History.startOfDay, but even then, it worked properly on a real device: forums.garmin.com/.../is-startoday-still-not-corrected

    I think it would probably be best to open a bug report.