Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis <bugs@gnu.support>]

* Tim Cross <theophilusx@gmail.com> [2023-01-29 23:38]:
> Yes, a timezone is defined by the offset it has from UTC

Other way around Tim, the UTC offset is defined for the time zone.

Time zone is not derived fro UTC offset, that does not work. UTC
offset is derived from time zone.

> Yes, a location time zone may change due to various reasons, such as
> daylight savings time, which also means the offset for that timezone
> changes.

Including that offset for that time zone can be changed for political
reasons, and did change in past, and some time zones may multiple UTC
offsets.

> However, it is the time zone definition which has changed.

Yes, and that change is about UTC offset. As time zone represents
location but UTC offset must be tied to it, otherwise how would you
know what time has the time zone?

> When you specify a date+time wiht an explicit offset, that offset is
> fixed.

It is fixed for that time moment. I have not said anything
different. 

I am only worried that if calculation go straight from UTC offset to
UTC offset without observig time zones, one will get proper UTC time,
but not proper representation in users' time zone.

I do believe that Org developers will make right decisions.

> That date+time is fixed. It will not change when daylight davings
> comes in or goes out because it isn't a time zone. It is only an
> offset and has no location reference and therefore no time zone.

For the above, I have already sent a map, by only observing the map,
one can see that time offset is directly related to time zone, it is
property of time zone, and it will change depending of political
changes, and it does change with daylight savings time. I have given
enough references, feel free to read it.

What does not change is the fact that UTC offset representation will
accurately provide UTC time.

From UTC time, by using user's time zone and various embedded
parameters one could arrive to user's local time, including users UTC
offset.

Excercise:

When there is daylight savings time (clock goes forward or backward),
it shall be clear that UTC offset changes as well. That means one hour
more or less must be accounted for in every calculations of Org
Agenda.

But by using UTC offset alone, one cannot even include daylight
savings time changes! As for that one needs time zone.

Here is another good reference:
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

,----
| Our Example
| 
| America/Coral_Harbour is a time zone (for simplicity, I will focus
| only on IANA* time zones). America/Detroit is a time zone. With laws
| as they are now, the America/Coral_Harbour time zone has an unchanging
| offset of -0500, or five hours “behind” GMT, which for our purposes
| here matches UTC. America/Detroit changes during the year from an
| -0400 offset to an -0500 offset. So sometimes, the good people of
| Coral Harbour and the good people of Detroit have the same
| offset. Sometimes, they don’t.
`----

What do you think, is that information true?

Does UTC offset "change" or "remain fixed"?

Is it possible for programmer to convert UTC offset by using direct
calculations?

Or programmer needs to know information about time zones?

This makes calculations of Org Agenda or future time stamps difficult
when using solely UTC time offset.

Time offset is best expressed as representation of time at that time
point, and is always derived from the time zone.

> Saying that an offset is a fixed value is very different from saying
> that a time zone has a fixed offset. I think this is where your
> confusion is coming from. 

I said neither of those. I never said that UTC offset is fixed. I am
trying to give you references that you understand what people agreed
on this planet.

I never said that time zone has fixed offset, some time zones have it
fixed, some not, as UTC offset changes for daylight savings and
political reasons.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/