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).
