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

[Max Nikulin]

Sterling, thank you very much for the list of references. I was not 
aware of EDTF activity or the proposal for JavaScript.
I do not mind to have better precision for timestamps. Minutes are too 
coarse. However I would consider with low priority.
I would prefer to postpone some discussions now. At the current moment 
just be aware than one more person may have another opinion. Redundant 
fields are useful for humans, in addition, they allow to detect 
inconsistency. Date and time format with spaces are more friendly to 
humans as well. "T" hampers readability. So I feel some kind of internal 
conflict trying to achieve following standards, backward compatibility, 
and human readability simultaneously. I am unsure what is the proper 
solution.
The following is what I consider as more serious issues:

On 27/01/2023 13:06, Sterling Hooten wrote:
>    Duration (object)
>          as a quantity characterizing a time interval. These can be
>          written in different formats.
Interval, duration, elapsed time are tricky. I do not have preferences 
whose definitions we should follow. Just an example: (info "(libc) Time 
Basics") https://www.gnu.org/software/libc/manual/html_node/Time-Basics.html
Notice that 1 day does not necessary means 24 hours. Depending on 
starting day (e.g. before DST) other relations may be used, either 23 or 
25 hours (usually). It is still 1 day. The way to specify interval 
should be chosen depending on application.
Another case is January, 31 + 1 month. It actually may mean last day of 
January, so expected result may be February, 28 or 29. This case 
February, 28 + 1 month (the same interval) is March, 31.
>    Local system time
>          Local system time is determined by applying the system's time
>          zone offset and year offset values to UTC. The Time of day
>          system value displays the local system time. Local system time
>          and system time are used interchangeably.
"System time" is often used in the sense of hardware clock and 
originated from the times when DOS or Windows required local time.
>    Time Zone
>          A place/region.
Do you consider e.g. Etc/GMT-8 or UTC itself as a time zone?

>    Floating time
>          A wall time value without time zone or offset information. E.g.,
>          2023-01-24 or 6:45pm.
A potential source of confusion with timestamp in seconds since epoch as 
a floating point number, see `float-time'. (info "(elisp) Time of Day") 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-of-Day.html#index-float_002dtime
> Org must first support
> fixed/absolute time instead of just floating time.
Am I wright "in addition" is applicable here in the place of "instead"?

> • Design and implement the time zone aware calendar system This is a
>    separate project.
Will not such decision ruin "every Wednesday at 3:00 PM" at the moment 
of DST transition? I would vote that IANA DB should be used for 
calculations despite I have not seen a library with perfect API. Though 
libc with some tricks may allow to do most of tasks. (Even in presence 
of limitations such as unavailable identifier of system time zone.) This 
is the main point of my disagreement. If real time zones are not 
implemented from the beginning then the will be never supported, so the 
whole bunch of code will be requiring throwing away while keeping 
support of some formats to read old files.
>    • We are able to defer to experts and 35 years of knowledge rather
>      than debate among ourselves
Experts may generate enough pain such as requirement to not support IANA 
timezone DB as it was in EcmaScript 5 (Chrome followed it, but in 
Firefox conversion between local time worked correctly).