Dual Clock Experiment

** CAUTION: This is Experimental and released for testing purpose ** ** NOW BC01 (https://apps.garmin.com/en-US/apps/028bc5f5-bf88-4925-8fea-1940d897c6e5) has the same feature as alpha, which requires newer firmware to avoid crash though. ** it's released as a public Beta ver. to test if the UTC time can be calculated correctly on actual devices ** ** Need help: please let me know if the UTC-0 (GMT) is correct or not on your device ** . Thank you for everyone who gave the result of testing!! Several people reported the wrong time offset on 2nd clock. Still we are not sure which CIQ API has the bug... so still welcome the new testing results. It will be very helpful if the test report is: - - make sure the DST of the 2nd clock is turned OFF (no red [S] mark on the right of 2nd clock) - - 2nd clock is set to UTC-0 And include: - - device model (i.e. 920XT, Fenix5S-plus, etc) - - firmware version (if you know it) - - your local timezone and DST (i.e. Pacific time, DST on) - - the UTC-0 time without DST on - - how do you sync the time? (manual, GPS, smartphone, etc) . == Buggy API? == Several CIQ API are in question, but behavior varies from model/firmware to model/firmware: * System.getClockTime().dst * System.getClockTime().timeZoneOffset * Gregorian.utcInfo(Time.now(), Time.FORMAT_SHORT) So need to know which model/firmware has what kind of bug.. . == Features == * Clock1: System time (user's timezone) * Clock2: Custom time (UTC timezone can be customized via Garmin Mobile/Express) * Clock2's summertime can be customized too * summertime indicator * Month calendar ** 1st-day-of-week can be set (Sun or Mon) with Garmin Mobile/Express * battery indicator, step-achievement-meter, etc . == Future plan == * This watch face is planned to be integrated into BC01 watch face (https://apps.garmin.com/en-US/apps/028bc5f5-bf88-4925-8fea-1940d897c6e5) . ==How to configure== https://support.garmin.com/en-US/?faq=SPo0TFvhQO04O36Y5TYRh5

== Test Result == * FR235/firm7.30: getClockTime().dst is wrong, but getClockTime().timeZoneOffset is correct when in PST zone on June 18 * vivoactive/firm4.40: getClockTime().dst is wrong, but getClockTime().timeZoneOffset is correct when in PST zone on June 18 * CIQ SDK 2.3.1/Win Sim: getClockTime().dst is correct, getClockTime().timeZoneOffset is correct when in PST zone, on June 18 * CIQ SDK 2.3.1/Win Sim: Gregorian.utcInfo() seems correct when in PST zone, on June 18 * (user's report): vivoactiveHR: On Aug.8th, GMT is off by one hour (shows 0250z when 0150z) when in PST zone (Seattle) * (user's feedback): fenix3/940: showing UTC off an hour. when setting local Afghan time and its only showing 3.5hrs difference on jun.9 * (user's feedback): vivoactiveHR: UTC 0 time is one hour fast on Oct.25 * (user's feedback): 920XT/9.40: UTC is off by one hour, for me it's one hour ahead on Sep.28 * (user's feedback): vivoactive/4.40: UTC 1 hour off now here 2.31 pm UTC 19:31 which should be 18:31 * 920XT/firm3.30: getClockTime().dst not work. getClockTime().timeZoneOffset is OK. PST on July * 920XT/firm9.90: getClockTime().dst not work. getClockTime().timeZoneOffset is OK. PST on July . == changes == ** support for newer models (245,645,vivo3, etc) ** experimental support for Fenix5S/S60/MARQ