TimeZoneOffset Question

Thank you very much, I will then use only the timezoneoffset, it is enough for the task.

Anyone know if there s there any update to this issue ?

BST has caught me out as everything worked well in the sim but was an hour out after BST on the watch

    var TimeUTC =  Time.now().value()    ;
    var tzo = System.getClockTime().timeZoneOffset;
    var TimeNow = TimeUTC + tzo;

The difference between the sim and the device. In once case, the timeZoneOffset includes the dstOffset and dstOffset will be 0. In the other, timeZoneOffset doesn't incluse dst.

so a function which gets offset and checks dst is required to manage this? Has anyone made this as it sounds beyond my skiils

Where you now use System.getClockTime().timeZoneOffset, use (System.getClockTime().timeZoneOffset+System.getClockTime().dst).

That should work on both the sim and device.

i'm on the UK, the above gives 7200 (in the sim) which is 2 hours. BST is 1 hour ahead of UTC, what am i missing?

put in some println calls with the two values and create a log on the real device so you can see the two values.

Here are scenarios I haven't been able to test but am curious about:

My 2 cents:

- Most computer systems internally keep time in UTC and convert to local time for display purposes (inb4 “there are systems from the 1980s which only store local time and/or are unaware of UTC”)

- A notable exception to the previous point would be something like a calendar appointment, which would naturally store local time and an associated time zone. Same with daily fitness / activity tracking, which of course would take local time into account to determine the end/start of a day (and ofc there have been bugs associated with this)

- Garmin FIT file timestamps are in terms of UTC (seconds since the Garmin epoch), and I wouldn’t be surprised if internal time was kept in UTC as well

- I’d guess that the majority of duration-related operations on a Garmin device are timezone-agnostic, unless there’s a specific reason that time zones have to be taken into account

So my guesses for your questions would be:

(EDIT: clarity)

1) no I think it will do the first alternative you listed (the right thing)

2) no I think it will do the first alternative you listed (the right thing)

3) doubt it, unless you have a way to get the coordinates of the next point, in which case you could use a LocalMoment on newer devices to determine the local time at that point.

Good insight! I assume by "no" you mean it will do the right thing. I agree.

For #3, the coordinates are in the route. Given the LocalMoment feature, that would be really nice to get "coordinatesAtNextPoint()".