How to get the time zone of current watch environment?

You may know what "unix time" is, but not everyone does.

DST is based on the perspective of "Today", so if it's the day that DST changes, should 24 hours ago be 10am or 11am?  Both can be considered valid.  I prefer the "today" perspective.

jim_m_58 said:

You may know what "unix time" is, but not everyone does.

Fair enough. You were replying to me so I assumed you were talking to me, especially since you already mentioned unix time without defining it.

jim_m_58 said:

DST is based on the perspective of "Today", so if it's the day that DST changes, should 24 hours ago be 10am or 11am?  Both can be considered valid.  I prefer the "today" perspective.

Not all perspectives are equally valid. There's one perspective which is overwhelming used in general purpose computing and there's another perspective which I've only seen on Garmin. (I'm excluding old/limited devices which don't even try to implement DST properly)

We already had this discussion but the future local time on January 1 00:00 UTC 2022 in New York does not change depending on whether today is February 1 2021 or July 1 2021.

Same as the timestamps on your files (saved as UTC, displayed as local) should not change based on the day you are looking at them.

And literally every OS (Windows, Linux, Unix, MacOS, etc.) implements it properly:

- i.e. If to calculate DST/TZ offset/local time for a given date, the DST rules for that date are used, not the rules for today.

All I can say is that it works one way in the simulator (since it obviously uses the time functions in the OS) and it works a different way on the watch.

Suppose I were to ask you the question:

- What was the local time/date in New York at the precise moment of the UNIX epoch (January 1,1970 00:00 UTC)?

- According to you, the answer changes depends on what today is.

- According to me and timeanddate.com, the answer is always the same:

https://www.timeanddate.com/worldclock/converter.html?iso=19700101T000000&p1=1440&p2=179

Jan 1, 1969 19:00

Of course some systems may not have historical TZ info so they won't be able to take into account historical changes in TZ rules. And no one can account for future unknown TZ rules. But at the very least, we can take into account the day in question, instead of looking at today.

But I'm guessing there's nothing I can ever say which will convince you otherwise.

FlowState said:

You were replying to me so I assumed you were talking to me

No, it's just part of the tread.  I'm addressing your post, not you.

When there are different perspectives, you pick one.  It's that simple. In this case, things are always related to "today" with no DST adjustments.

jim_m_58 said:

No, it's just part of the tread.  I'm addressing your post, not you.

Fair enough. I still don't get why you didn't define unix time originally, since you feel that nobody knows what it is in a discussion about time zones.

Also, you'll note that in computing, local timestamps are often specified with timezone offsets. e.g.

https://tools.ietf.org/html/rfc3339#section-4.2

2021-01-03T21:37:31-05:00

I think it goes without saying that the "-05:00" in the above timestamp refers to the local timezone offset on Jan 3, 2021, not "today".

jim_m_58 said:

DST is based on the perspective of "Today", so if it's the day that DST changes, should 24 hours ago be 10am or 11am? 

I think the question you're trying to ask is:

"If today is the day that clocks moved forward 1 hour for the beginning of daylight savings time, and it's currently 11 AM, should 24 hours ago be 10 AM or 11 AM?"

Believe it or not, there is an unambiguous answer to this question, and it's 10 AM. To suggest that the answer is either 10 AM or 11 AM, and that both answers are equally valid, is ludicrous.

jim_m_58 said:

When there are different perspectives, you pick one.  It's that simple. In this case, things are always related to "today" with no DST adjustments.

That's not true. In this case (Garmin), the DST adjustment that's applied is based on "today" which doesn't make sense for dates which aren't today. For a given date, the DST adjustment that's applied should ideally be based on the day of the year (and the year), for the given date. In the absence of historical TZ info (or for future dates), maybe we have to use info for the current year. But it doesn't make sense to use DST info for the current date when we're talking about a different day of the year.

There are standards in computing which is required for different systems to talk to each other.

FlowState said:

I still don't get why you didn't define unix time originally, since you feel that it's nobody knows what it is in a discussion about time zones.

You seem to like to put words in my mouth.  I never said anything close to that.

Sorry, I shouldn't have said that.