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

Surprised there has been no response to this. Am I the only one experiencing this issue?

What are you trying to do with this?  If you want to detect DST, the value is only valid at your location, but not universal, as DST starts and stops at different times in different places.  It's DST in the US right now, except in two states that never change, and it's not DST in Europe.

This is a big part of the tzmap file that gets downloaded to devices a couple times a year.

Yeah, I am trying to detect the local DST which is currently in effect in my location (aka, my watch adjusted last weekend with the DST cutover (the time is correct), but the DST value has not changed on my watch). 

I am currently side loading the WF to test it. Would this have any impact? Its just odd the DST value is correct on the simulator and not on the watch. 

Any values I can display on the WF to verify the simulator and watch are operating under the same parameters? What properties does the tzmap key off of? 

This is the way it's been all along in CIQ.  In this case the watch and the sim don't do the same thing and if I recall it has to do with what's available on a pc/mac but not on the watch..

Can you clarify.... how is the watch recognizing DST in displaying the correct time but not reflecting this in the systems DST value? 

To further clarify on my implementation:

• All my time calculations, including the time displayed, is based on Time.now()
• I am reading system.getClockTime().dst to modify my sunrise/sunset calculations, but otherwise do not use System time. 

I should also note, the factory WFs are recognizing DST and are properly adding an hour to sunrise/sunset calculations, after 3/14, suggesting the system variable should also indicate DST as 3600 vs. 0. 

When you calculate sunrise/set you have a moment I'd guess, and when you use Gregorian. Info, DST is taken into account, and you don't have to adjust for it

Have you looked at using timeZoneOffset?  As that changes correctly on the watch.

Don't know your code, so don't know. Don't post your code, but you want to debug what's happening in your code.

1) I'm not sure how anything you do with two moments could affect the value of ClockTime.dst, as that's based on the current time.

2) Yep, on my 935, dst has an incorrect value of 0 (and on the simulator, it's the correct value of 3600). However, the timeZoneOffset value is correct.

Over 6 years ago, AlphaMoneyC said this:

https://forums.garmin.com/developer/connect-iq/f/discussion/127/sys-getclocktime-never-provides-a-value-for-dst

In preview 2 we are adding a field in ClockTimer named timeZoneOffset which gives the number of seconds from UTC the current time is. Long term I think we will probably remove the DST flag, as I'm not sure it adds a lot of utility.

Sounds like it was never fixed (or this is a regression) and they forgot to remove it?

¯\_(ツ)_/¯

I'm not a fun of having stuff documented in the API which just doesn't work.

3) Instead of calculating the delta between current local time and UTC manually you could use ClockTime.timeZoneOffset (as Jim suggested), which gives you the same information.

Having said that, I don't see how the delta can be "wrong", unless either the local time or UTC is wrong. DST wouldn't be applied to UTC as that defeats the whole purpose of UTC (to be the standard time against which all other times are offset.)

I'm also not sure how getting the delta between local time and UTC is going to help you with determining whether you're currently in daylight savings time or not, unless you're going to select another day of the year which you're guessing wouldn't be in DST, get the UTC/local delta for that, and compare the two deltas.

I suppose one workable algorithm could be:

1) Get delta between local time and UTC for July 1 (guaranteed to be unambiguously either inside or outside of DST, if applicable)

2) Get delta between local time and UTC for December 1 (guaranteed to be the converse of 1)

3) The lower of the two deltas is the standard offset from UTC. The greater of the two deltas is the DST offset from UTC. (If the offsets are the same, DST is either year-round or not applicable, in which case you're in trouble as you can't distinguish between the two scenarios.)

4) Get the delta between local time and UTC for the current date. If the delta is equal to the DST offset (or greater than the standard offset), then you're in DST.

EDIT: a quick test in the sim shows that if I create a moment using Gregorian.moment():

- The original input to Gregorian.moment() is interpreted as UTC time (not sure why the doc implies the opposite...)

- Gregorian.info() returns local time (seems to be correctly adjusted for DST/non-DST dates)

- Gregorian.utcInfo() returns UTC time

EDIT: Unfortunately this only works properly in the sim. On the real device, no matter what date I pass in to Gregorian.moment(), info() returns a time that's adjusted for DST as if it's the current date (which is DST where I live.)