time zones

It seems odd that a watchface would work, and an app wouldn't. How are you calculating timeSecs in your example for the app above?

1.  When time is set by GPS, it knows your location, and using tzmap (it's a file that gets updated a couple times a year that you can't see), using both the date and your specific location, gets the utc offset.  This is also how Daylight Savings Time is done, as that depends on the location as well as date.

When you set an alt TZ, there's a widget that allows you to show the time in that tz, but doesn't actually set that on the device as the tz. When you are in that widget you can add/change to other alternatives by pressing "start".  Right now I'm displaying two alt tzs in the widget and my WF is still local time.

2. It's probably easier to do in the sim by setting the tz on your pc/mac itself.

Thanks Jim for your insights.

How do I join the coven of Garmin dev wizards that have access to these secrets? I have been a Garmin app dev for over three years and am aware that there must be a book of magic spells much bigger than the abbreviated version provided in the SDK! How did you learn the secret of tzmap?

Your suggestion of using the sim and tweaking the time in my PC might provide some useful testing, but it doesn't really allow me to close the testing loop of running my app on an actual device. I guess I'll have to do some travelling to do that!

Actually, tzmap isn't really a secret!  There's usually an update right before places start switching to DST and another right before DST stops, and it's sent to all garmin devices that use GPS for time (including my car nav system).  And when that happens, people in the device forums ask what it is.  I know there are also threads here about it.  Think a WF that displays multiple tzones.  I know one suggestion I had in the past was a way to query it, with say the lat/lon of Paris, and be able to get the current UTC offset for Paris (DST changes at different times in different countries)

I think that if people in the device forum have to ask what it is, then doesn't that make it a secret?

The concept of "before places start switching to DST" is a bit grey, as, for example, there's nearly a month between Australia going on to DST, on Oct 6 2019 and the US going off DST on Nov 3 2019, and the UK on 27 Oct 2019! (It makes scheduling calls with colleagues in the US and UK extremely challenging! )

How do we know when this TZMap update occurs? Does it arrive as a  separate package?

No, there are always new users, and they watch every update they get, and with tzmap being kind of infrequent, people ask.

It arrives like any FW update, and in GE, you can even see the changes "such and such a place changed their dates for DST"

I still maintain that if it isn't in the SDK documentation, and is relevant to developers (as this discussion clearly indicates is the case) then it's a secret.

It's not an SDK thing.  It's a basic function on devices.  As I said, I even see it on my car nav system!  You just need to venture into device forums from time to time!

Garmin has determined that by investing in the API, developers will be enticed into freely adding functionality to their products which in turn provide a marketing edge in this highly competitive market. 

Garmin survives on the sales of new devices, and people are buying Garmin watches because of our apps. I know that from testimonies from sailboat racers around the world who have bought a Garmin watch specifically to run my app.

Garmin might adopt a folksy theme with cute animal references like MonkeyC etc., but let's not underestimate the significance of the opening line of the Programmers Guide:  "Developing on wearable platforms is new and challenging" (my emphasis).

It is challenging, and having been enticed into their ecosystem, I, as a "volunteer developer", expect Garmin to make the API live up to a professional level of excellence. And there are two components to that: 

1. the quality of the code and 
2. the quality of the supporting documentation.

The code in the SDK is under regular maintenance and development, with the hiccups that are inevitable in any large software development program. 

It wasn't always thus. Three years ago I was forced to abandon the platform due to continued shortcomings in the SDK. I returned last year on the assurance that my major issues were rectified, which ultimately was justified. 

The documentation on the other hand falls well short of that, forcing us to resort to forums such as this, which relies on other developers' hard-won knowledge to provide vital insights to the usage of the API.

How hard would it be to explain in Module:Toybox::Time::Gregorian::Info  that the representation the Gregorian date is based on the local time, and then explain that it can use TZmap and the GPS location, and what the TZMap is and how it is deployed?

As a professional developer, I am fully aware of  the challenges of maintaining an acceptable level of documentation, and whenever I field questions about the operation of my app, I update my documentation to fill the hole.

That process seems to be missing, or glacially slow in the API docs.

OK, maybe I'm old fashioned, after all I wrote my first program, in Fortran in 1969, but I feel that we developers should be pressing Garmin for professional excellence in both components of the API.

Let us not forget that the Connect IQ API is a marketing strategy to sell devices.

I couldn't agree more. I just bought a garmin device over other alternatives because I took a look at the app store and there were several apps I wanted to use. Then I took a look at the dev platform and it seem to be professional, so I decided to buy a garmin and start developing for it. Sadly I faced quite soon that docs were not as good as it initially looked. 

Hopefully garmin takes a more dev oriented approach. There are a lot of orphans on the pebble side!