Dual Time Zone Face

You can access the offset from UTC time (negative values are west) via the timeZoneOffset member of the object returned by Sys.getClockTime().

Support for user-specified settings that can be changed via Garmin Connect Mobile is supposed to be a feature that is coming to ConnectIQ. I've got no idea where it is on the priority list, but this would be necessary to be able to allow the user to specify settings for your watch face.

Travis

Travis,

Thanks for the fast answer - I figured it was somewhere but could not find it. I guess my first dual face will just be for those of us in the mountain time zone :-)

Paul

I'm going to make you cranky now, as Mountain Time isn't all the same, as Arizona doesn't do Daylight Savings! :)

In windows for example, there is a time zone called "Arizona" with the the difference being that DST isn't used. The stuff that travis pointed you do also has a "dst" method, so you'll need to include that offset and a way to set it if is used, in the event it can be user defined. Hawaii also doesn't use DST.

If the goal is to display UTC time and local time, that would work fine. Anything else is going to have some quirks.

As pointed out above, daylight time isn't observed in all locations. Outside of the US, some time zones use weird offsets. Without access to the daylight rules for the time zones, your watch will be wrong during daylight transitions. i.e., on November 1 at 1:30am PT, it would usually be 2:30am MT but due to the way daylight transitions work, it would actually be 1:30am MT as well since they fell back 1 hour at 2am. Not to mention that daylight rules can and do change. Daylight time stuff is really fun.

If you don't care about it being perfect, then it is pretty simple, but you have to realize that it isn't perfect. Eventually when parameters can be passed to watch faces, you could use them to build daylight rules and make it work.

Travis

Thanks all - even for the headaches!

Right now I will plan on doing the best I can, but realize that things are not quite perfect. I look forward to hopefully increased capabilities. Given what you taught me and some more research on DST I can make it pretty good.

To test some of the crazy - is there any way to change the timezones in the simulator. I figure I can mess with the windows clock if need be, but it would be nice if I could do it in the simulator instead.

Thanks,

Paul

I don't think there is a way to change it in the simulator. That said, I wouldn't be so sure that the DST rules used when running under the simulator are those provided by windows. If that is the case, you are very likely to get different behavior when running on a device.... Just another layer of stuff to mess with.

trying to give a bit back...

I am moving forward with a dual watch face dedicated to those of us in the Mountain Time Zone not in Arizona. I thought I would provide a bit of code for how to determine the dates for the start and end of DST in the US, until congress decides to change it again ;). From there, I figure I can test if mountain time is in DST or not. Any suggestions on how to tighten up the code or make it more efficient would be welcome.

It would also be nice if there was a way to set up a home timezone and check that timezone to see if DST is in effect. It would make the creation of a dual face watch more practical across the globe. After digging into the various implementations of DST around the world my head hurts a bit, I imagine that this code is somewhere in the base FW of the watch, it would be a shame to have to duplicate it.

Thanks for all the help from the forum, I could not have got this far without a lot of past comments and the search tool.

Paul


//Let's figure out we are in DST
//get the current info
var localtime = Time.Gregorian.info(Time.now(), Time.FORMAT_SHORT);
//find the moment that DST starts second sunday in march
//start testing on the 8th, the first possible second sunday 2am
var testDateMoment;
var testDate = localtime;
//start off testing on March 8th at 2am
var i = 7;
do {
i ++;
testDateMoment = Time.Gregorian.moment({:year => localtime.year,
:month => 3,
:day => i,
:hour => 2,
:minute => 0,
:second => 0});
testDate = Time.Gregorian.info(testDateMoment, Time.FORMAT_SHORT);
}
while(testDate.day_of_week != 1);
var DSTStart = testDate;
Sys.println("DST starts on " + DSTStart.day.toString());

// now to find the end of DST first sunday in November
i = 0;
do {
i ++;
testDateMoment = Time.Gregorian.moment({:year => localtime.year,
:month => 11,
:day => i,
:hour => 2,
:minute => 0,
:second => 0});
testDate = Time.Gregorian.info(testDateMoment, Time.FORMAT_SHORT);
}
while(testDate.day_of_week != 1);
var DSTEnd = testDate;
Sys.println("DST starts on " + DSTEnd.day.toString());


You just reminded me that I wrote code to do a binary search to find the transitions for work. You should be able to do it in MonkeyC, but it won't be quite as easy because the Gregorian.info() function doesn't provide a is_dst flag like localtime() does in C.

It seems to me that there is a enhancement request that should be filed. For countries that follow daylight savings time in the northern hemisphere, in the fall we roll the clocks back one hour. When the clock ticks past 1:59:59am daylight time, the next second is 1:00:00am standard time, and we repeat that hour again. The ConnectIQ functions don't provide a way to deal with this. It seems that there is only one interpretation of the time 2015-11-01T01:01:00. This is wrong.

It seems that to avoid this, the Gregorian.info() method needs to provide some sort of indicator that the time is in DST or is not in DST, and the Gregorian.moment() method needs to take an optional indicator. Having these bits makes it pretty simple to detect the time zone rules used by the device with a binary search.

Travis

Even without a dst flag, I think you should be able to detect discontinuities in the local time. i.e., given a unix timestamp for a known HH:MM on the 15th of a month, add 30 days (30*24*60*60 seconds), then extract the hour and minute values in local time. If the HH:MM value is less than the value you started with, you know you lost some number of seconds when transitioning from daylight time to standard time. If the value is greater then you know you gained some number of seconds when transitioning from standard time to daylight time. You should be able to use this with a binary search to find the transitions for a given year in any location.

Also note that without the addition of a dst flag as suggested above, you have no way to know if you are currently in a zone that does not recognize daylight time or if you are in standard time. You could make some assumptions, but then that would break down for southern hemisphere locations.