Having trouble with date picker in phone settings

I need to get the Month/Day/Year from the phone settings and I set date in settings on the phone to 1/1/2021 and I am getting 12/31/2020:

var countdown = Application.getApp().getProperty("CountDownDate");
var infoC=Gregorian.info(new Time.Moment(countdown), Time.FORMAT_SHORT);

var cyear = infoC.year;
var cmonth = infoC.month;
var cday = infoC.day;

System.println(" MyWatchFaceView - onUpdate - countdown:"+countdown+" cmonth:"+cmonth+" cday:"+cday+" cyear:"+cyear);

-------------------------------- output

MyWatchFaceView - onUpdate - countdown:1609459200 cmonth:12 cday:31 cyear:2020

Top Replies

All Replies

0 waterkip over 2 years ago in reply to FlowState

I see what you mean. It is 00.55 local time and getting tired. Tomorrow

0 FlowState over 2 years ago in reply to waterkip

Yep it’s super unintuitive. Have a good one! (It’s the same time for me but I just finished a run + workout and I can’t sleep lol.)

0 waterkip over 2 years ago in reply to FlowState

I just finished a beach tennis training a couple of hours earlier, so I got slammed by melatonin.

My clarification is more, hey, you know https://forums.garmin.com/developer/connect-iq/f/discussion/306154/what-s-the-best-way-to-handle-a-long-list-in-settings that thread, we need tools to convert things to other timezones. It is ok that they (Garmin) store it in UTC, but gimme the tools to timezone it propperly.

0 FlowState over 2 years ago in reply to waterkip

waterkip said:
My clarification is more, hey, you know https://forums.garmin.com/developer/connect-iq/f/discussion/306154/what-s-the-best-way-to-handle-a-long-list-in-settings that thread, we need tools to convert things to other timezones. It is ok that they (Garmin) store it in UTC, but gimme the tools to timezone it propperly.

Agreed, although I think it's more of a tangential issue compared to the main objection of "hey, what Garmin is doing is wrong". Yeah, strictly speaking it's wrong, but you can work with it if you know what they did and understand why.

As for displaying times in other timezones, if you're using CIQ >= 3.3 ("System 5" *) then you can use a LocalMoment, which takes a UTC time and location as input, and gives you back local time in that location's timezone:

developer.garmin.com/.../LocalMoment.html

This is the closest thing to what you are asking for. If you want to support several timezones in your app, you can maintain a mapping of timezones to coordinates.

Otherwise, you can maintain a mapping of timezones to UTC offsets and DST rules, then use that to convert UTC/local times to other time zones. As discussed in the other thread, that's actually a lot of work and needs to be constantly maintained if and when DST rules change, but it's not impossible.

(* My pet peeve here is that System 5 is actually CIQ >= 3.3 for CIQ 3.* and CIQ >= 4.1 for CIQ 4.*, but nowhere is this called out in the docs. For example, CIQ 4.0 doesn't have CIQ 3.3-specific features. This seems to be something we're just "expected to know". It also means that it's impossible to include/exclude System 5 properly using the "min API level" property in the app manifest.)

Speaking of time issues, there are these bugs (no idea if they've been fixed):

https://forums.garmin.com/developer/connect-iq/i/bug-reports/gregorian-info-handles-dst-incorrectly-for-dates-other-than-now-today-works-in-sim-not-on-device

Gregorian.info() handles DST incorrectly for dates other than now/today (works in sim, not on device)

The gist is that the DST rules for today are applied when converting a UTC time to local time, as opposed the DST rules for the date in question, which makes absolutely no sense.

There's also this:

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

ClockTime.dst is 0 on the watch, correct value on the simulator