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

jim_m_58 said:

I happen to live in a US state that doesn't do DST which is another wrinkle.

Then the TZ info for your timezone location would surely account for that. Same as Saskatchewan (no DST) has its own "time zone" which is basically Central Time year-round.

jim_m_58 said:

The day after DST goes into effect at say 11;00, is 24 hours before that 10:00 or 11:00?

The existence of ambiguous edge cases doesn't prevent us from trying to even attempt a solution that covers 99% of use cases.

And if you're always storing times in UTC and converting to local time only for display, that kind of issue should not exist (for the most part).

jim_m_58 said:

The issue isn't the tzmap data, it's that the way things are accessed.

Right, and my point is that regardless of the implementation details:

1) the current way is unambiguously wrong. Converting UTC to local time for a date other than today should *not* produce different results depending on what today is.

2) there is a way to implement this which isn't expensive (in terms of storage, code, etc.), even on embedded devices with limited resources. e.g. the POSIX TZ variable is a good example:

https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

Or is the argument here that "we can't implement DST offsets perfectly (for dates other than today), so may as well not even try"?

What I presented is not an edge case, and happens all the time with things like watchfaces with countdowns timers, 8hr forecasts, etc.

The way it works is just another way to look at things.  Everything In the past or future, is based ion "today".  You might not agree, but may actually be less confusing to users than using those specific dates for DST.

I'm in the same tz as a few other states (same name), so that name doesn't really tell you.  I remember when windows added something special.  Some device I have a "use DST" setting, which helps, others I have to change the tz to use the correct time.

jim_m_58 said:

What I presented is not an edge case, and happens all the time with things like watchfaces with countdowns timers, 8hr forecasts, etc.

Again, that's why you would deal with UTC time whenever possible, and convert to local time only for display. Of course, this assumes that your UTC-to-local time conversion function actually works....

I'm not sure what your point is, though. Are you saying that it's impossible for watchfaces to properly implement countdown timers, 8hr forecasts, etc. around the time of a DST/non-DST transition?

Even if that were true, I still don't see what the relevance is to the problem of converting UTC time to local time for dates other than today, which has been handled on countless platforms with a greater degree of accuracy than this implementation.

"Problem X is hard, so therefore solving related Problem Y is impossible."

jim_m_58 said:

The way it works is just another way to look at things.  Everything In the past or future, is based ion "today".  You might not agree, but may actually be less confusing to users than using those specific dates for DST.

But that's actually not the way it works in the real world.

The local time in New York at January 1, 2022 00:00 UTC does not change depending on what today is.

That is an unambiguous fact and not really a matter of opinion.

Similarly, I was born at a certain point of time in the past. If you were to ask me the exact local time of my birth, that answer would not change depending on what today is.

If several people in different locations agree to have a video conference call at some point in the future, that future date and time does not change depending on what today is.

jim_m_58 said:

I'm in the same tz as a few other states (same name), so that name doesn't really tell you.  I remember when windows added something special.  Some device I have a "use DST" setting, which helps, others I have to change the tz to use the correct time.

I think you're missing the point. Saskatchewan (no DST) is also in Central Time (which is used by many places which have DST), but it has its own entry in the Windows time zone list.

If you tell Windows that you live in Saskatchewan, you won't get DST, you'll be in Central Time all year round. If your phone detects that you're in Saskatchewan, the same thing will happen.

As another example, I see that Windows has a separate timezone entry for Arizona. And sure enough, Arizona does not support DST. If you look at Windows' list of "timezones" it's really a list of timezones/locations, where certain locations in a given timezone have different DST rules than other locations in the same timezone. e.g. Arizona and Saskatchewan have their own entries. Saskatchewan doesn't literally have its own timezone, it has its own timezone legislation.

IOW:

Windows has the following "timezone entries":

- Mountain Time (UTC-7). This is really "Mountain Time with DST"

- Arizona (UTC-7). This is really "Mountain Time without DST"

I'm sure your phone handles the lack of DST in your state just fine.

Sorry, but it boggles my mind how you think none of these problems have already been solved a million times.

The POSIX standard has been around for 30 years.

jim_m_58 said:

I remember when windows added something special.  Some device I have a "use DST" setting, which helps, others I have to change the tz to use the correct time.

Yeah, those devices and platforms only have to have that "use DST" setting because they don't have up-to-date/granular information on timezones (based on your location.) I think you'll find that most modern devices don't have that option. I'm guessing most devices which had "use DST" came from before an age of constant internet connectivity, where things like timezone databases can be updated on-the-fly as legislation changes (e.g. see the current proposal for year-round DST), and also because they have had limited storage to store all of the current rules. Probably also because they didn't have location services, and didn't want to show people a long list of timezone/location combos (the list in Windows has dozens of entries.)

Notice that Garmin watches do not have a "use DST" setting. That tells you something, namely that the device is able to figure it out for itself.

Anyway, my main point is that if Garmin knows whether it's DST or not in your exact current location for today, and it seems that it does, then it only needs two additional pieces of information to work properly for past and future dates (disregarding any changes in DST rules):

- The date that DST starts in your location

- The date that DST ends in your location

So if you're arguing that this is an impossible problem to solve, I find that very hard to believe.

There are long-standing issues with DST handling in the simulator. There are bugs that have been filed, but they always seem to slide down the bottom of the priority list.

But in this case the watch is not giving me the correct DST value -- the simulator is actually correct. 

• My current location is PST (UTC -8)
• My watch time is currently UTC -7 (PST + DST offset)
• The watch TZ Offset value is currently -7
• The watch DST value is currently zero (i.e., UTC -8) -- this value should be 3600 for my location. 

I took another look at my code and outputting a UTC value does not help. This is because I am rendering the sunrise/sunset as pointers on a 24h ring, so understanding when DST is in effect is relevant for translating the sunrise/sunset angle to a proper ring position.

This WF is primarily for myself (my first WF) so I can get away with hard coding my known zone (e.g., UTC-8) and add the tzOffset value to get the DST value. Its a shame though as I was hoping to eventually publish this WF but I would now need to sort out the implementation of a tzmap.... <sigh>

Also, its worth clarifying (for everyone on the thread) I am seeing the issue on my watch (Fenix 6x), which is not returning the correct DST value. The simulator is working as expected for me.