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

[Jean Louis <bugs@gnu.support>]

* Tim Cross <theophilusx@gmail.com> [2023-01-31 01:05]:
> Jean,
> 
> you have a very irritating habit of changing the topic of the discussion
> in order to push whatever you feel you want to argue about. My response
> to you had nothing to do with all the irrelevant points you insist on
> repeating despite numerous attempts by many to explain why what you are
> sending is adding little value.
> 
> I was simply responding to your response to Sterling's glossary of
> definitions where you argue against defining offset (the term) as a
> fixed value.
> 
> I will not be engaging with you further.

UTC offsets have been assigned by authorities, that they are
political, change due to daylight savings -- and for that reason
cannot alone as such be used for calculations of time, for example in
Org Agenda.

I fully understand that representation of time with UTC offset alone
is as such fine and good, never said anything opposite.

Adding some hours, days, as absolute time to it, or deducting, it is
of course always possible.

I have given facts, and references with the sole intention to help in
understanding so that Org programmers do not start relying on UTC
offset alone, as that is not how other programs work.

My intention is of course not what you stated. 

I have not get bad intentions. Please do not assume it.

You got references showing that it is politically related, that UTC
offset does change suddenly, and for that reason one cannot just use
it for calculations in program.

I am fully aware and never stated different, that once you place UTC
offset as representation somewhere in text, that it is offset from UTC
time and that time point is fine and remains fixed.

What I am saying is that calculating that time point to local time is
tricky, as using UTC offset alone is not going to give accurate local
time unambiguously. Sometimes it will give, but sometimes not if
programmer uses direct calculation.

"fixed" is thus only fixed in context of representation.

I was thinking we speak here of using time objects for calculating
times in future, not only of representation, as I did not argue about
it.

UTC offset is representation as it has to be derived from time zone to
be represented as such. Provided that program knew how to derive
correct UTC offset, that is "fixed" as representation.

Programmer can now add some time or deduct some time and directly
added or deducted time will also represent some point in time.

But will it be that time that user was thinking for another user in
different time zone?

Unambiguously is not possible to use only UTC offset for such
calculation, due to reason that UTC offset changes how authorities
decide on it.

Let me try to make exercise example both for me and other people, and
feel free to correct me:

From:
https://www.timeanddate.com/news/time/europe-starts-dst-2022.html

,----
| Daylight Saving in Europe
| 
| Time changes in Europe are synchronized. According to the current EU
| law, DST starts on the last Sunday of March and ends on the last
| Sunday of October. Participating countries are:
| 
| The European Union (EU), including Bulgaria, France, Germany,
| Italy, Poland, and Spain. 
`----

- Last Sunday of March in 2022 was 27th March 2022, or 2022-03-27

- the clock forward had to be done at 1 hour UTC time on March 27th
  2022, because Berlin before 27th March 2022, was with UTC offset +1,
  that time should be 2022-03-27 01:00 UTC time, which is also same as
  Berlin time. 

- Let us say one second after 2022-03-27 01:00 UTC time or UTC +1, the
  clock will not be 2022-03-27 01:00 UTC, but 2022-03-27 02:00 UTC,
  loosing one hour, as clock moved forward. UTC offset changed
  suddenly.

- person in Berlin plans meeting for on 26th March with somebody in
  China, for 27th March 2022 at 10 o'clock, how is he going to
  represent this? Let us see, maybe as
  following. <2022-03-27 Sun 10:00>

- on 26th March 2022, the UTC offset in Berlin was +1

- on 26th March 2022, when user exports that appointment, the time was
  for example 16 o'clock, something like 2022-03-27 16:00+01 because
  UTC offset was +1 at that time.

- If Org programmer decides to use UTC offset only for calculations,
  then the program will know that UTC offset in China is +8 hours.

- What will program do? By using UTC offset only, program will know
  that now is 2022-03-27 16:00+01 and that timestamp like
  <2022-03-27 Sun 10:00> is also with UTC offset +1 (which is not
  true). But program would think it is 2022-03-27 10:00+01 if program
  uses UTC offset only.

- Program may wish to provide new UTC offset for Chinese user, by
  knowing that in China on 26th March 2022, at 16 o'clock is +8 and
  not +1, the difference of 7 hours will be added on the time stamp of
  appointment, which is 2022-03-27 17:00+01

- However the time of 27th March 2022 at 10 o'clock Berlin time the
  time in Shanghai was 16 o'clock.

- While Chinese user was in restaurant at 16 o'clock and waiting for
  appointment at 17 o'clock, because he has got calculation with UTC
  offset only, he will be surprised that he missed the appointment.

- Because Org used UTC offset for calculations considering it
  "absolute" or "fixed".

Conclusion:
-----------

Using UTC offset time stamps alone cannot be used unambigously to
represent time for Org Agenda or shared appointments or meetings, due
to possible political changes and daylight savings times.

-- 
Jean

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

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