System.getClockTime().dst is 3600 in the simulator but zero on my watch.

I am experiencing the same DST issue reported 4 years ago.

Watchface, Sys.getClockTime().dst is alsway zero on watch when daylight saving is on - Discussion - Connect IQ - Garmin Forums

System.getClockTime().dst provides the expected value of 3600 in the simulator but the value is zero on my watch (Fenix 6x). The previous post indicates a ticket was opened but its not clear if there was any resolution. Any suggestions?

0 FlowState over 4 years ago in reply to FlowState

Having said all of that, I have no idea how watchfaces account for the 1-hour discrepancy in sunrise/sunset due to DST. (I don't write watchfaces.)

EDIT: Looking at one algorithm, it looks like it uses the current timezone offset from UTC. It seems like this would be an issue during daylight savings time...

https://github.com/warmsound/crystal-face/blob/master/prototypes/suntimes.html

github.com/.../DataFields.mc

EDIT: I thought about it some more, and maybe the fact that during DST, your UTC timeZoneOffset is adjusted by 1 hour *and* your local time is also adjusted by 1 hour means that the algorithm works properly.

Considering that there's a ton of watchfaces that seem to calculate sunrise and sunset properly, having the correct dst offset can't be a prereq for this.

0 FlowState over 4 years ago in reply to FlowState

I opened three tickets for the OP's issue and the 2 related issues I found:

https://forums.garmin.com/developer/connect-iq/i/bug-reports/clockinfo-dst-is-0-on-the-watch-correct-value-on-the-simulator

https://forums.garmin.com/developer/connect-iq/i/bug-reports/docs-for-gregorian-moment-imply-that-the-input-is-in-local-time-gregorian-info-and-utcinfo-suggest-otherwise

forums.garmin.com/.../gregorian-info-handles-dst-incorrectly-for-dates-other-than-now-today-works-in-sim-not-on-device

0 Retsof81 over 4 years ago in reply to FlowState

Wow, thanks for putting in the time to research this and post bugs.

I took a closer look at the my functions and the moment comparison is used to calculate the time zone offset (looks like ClockTime.timeZoneOffset is a simpler way to do this).

In hindsight, I had pieced together the functions from examples, so I wasn't sure if DST was a big impact. I ran some tests (adding/subtracting a couple of hours to the tz offset) and it turns out the tz offset does not really affect the sunrise/sunset calculation -- at least nothing close to representing a proper DST offset in the output.

In my case, the sunrise/sunset calculations are effectively independent of the local time displayed on the watch -- the output is in degrees from solar noon. To display this properly, I need to identify when DST is in effect so I can offset the output when converting degrees to hours.

Using Sys.getClockTime().dst would have been ideal for this scenario. I will take a closer look at your findings in the bugs. Maybe there is something in there I can work with.

0 FlowState over 4 years ago in reply to Retsof81

No worries!

So just to dbl-check, you don't think the following algorithm which apparently only uses the TZ offset as a correction (and disregards DST) would work properly? I haven't had time to really examine it closely or think too hard about it.

github.com/.../suntimes.html

github.com/.../DataFields.mc

0 Retsof81 over 4 years ago in reply to FlowState

Oh, interesting... I think I may have a solution from the examples... in my code, I am displaying the sunrise/sunset using local noon as my starting point (e.g., sunset = noon + 6h, which would always display 6 PM, regardless of DST), but it looks like the example is applying their starting point as noon UTC and *then* adding the TZ offset to those values.

This alt approach could address my DST offset issue (if the TZ offset is including DST, which it may not per your feedback). I will try this out and and report back. Thx!

Summary:

I was attempting (sunset = <local noon> + <solar offset> + DST), but I could possibly accomplish the same with (sunset = <UTC noon> + <solar offset> + <TZ offset>)

0 FlowState over 4 years ago in reply to Retsof81

No worries!

Retsof81 said:
This alt approach could address my DST offset issue (if the TZ offset is including DST, which it may not per your feedback).

The TZ offset does correctly include DST on both the sim and device, *for the current date/time*.

The bug I found occurs when you convert a UTC time to local time, for a date other than today. On the sim this works correctly (DST offset is applied correctly for the given date). On the real device, the DST offset is apparently applied as if the provided date is today, which is clearly wrong.

So I think you should be good.

0 jim_m_58 over 4 years ago in reply to FlowState

The thing is, the tzmap date is only used for "today", and for a date in the past or future, doesn't know when exactly it changed, so if it's DST, it doesn't know for even 1 day in the past when it started.

0 FlowState over 4 years ago in reply to jim_m_58

No kidding. That doesn't change the fact that it appears to be a bug.

1) it's not documented

2) it's not expected

3) the behavior in the simulator (once again) does not match the real device behavior

If Garmin is unable to consistently provide the correct local time for dates other than today, that should be documented IMO.

0 FlowState over 4 years ago in reply to FlowState

And if you're thinking "it's impossible to implement this without importing a huge TZINFO DB that won't fit on watches", I've worked with a cut-down version of this kind of thing on embedded devices.

You just have a short (~30 char) TZ info string for each time zone, and you assume that the DST start and end days are the same for all years.

That covers like 99% of the cases.

(And obviously no scheme can perfectly account for dates in the future, when we don't know what DST legislation changes will happen in the future.)

0 jim_m_58 over 4 years ago in reply to FlowState

The issue isn't the tzmap data, it's that the way things are accessed.

I happen to live in a US state that doesn't do DST which is another wrinkle.

The day after DST goes into effect at say 11;00, is 24 hours before that 10:00 or 11:00?