Thanks for the quick feedback! > On 2023-01-27, at 08:09, Ihor Radchenko <yanta...@posteo.net> wrote: > > Following ISO and other standards is indeed a reasonable idea. However, > the standards are not necessarily designed for human consumption. > In contrast, Org mode is designed to be read by humans as well, even > without Emacs - just as plain text. > > Design for human consumption is one of the reasons we do provide the > redundant information like week day (I personally did find it extremely > useful on multiple occasions) and do use spaces, deviating from ISO. The > above ISO example is barely readable by humans. Another example from > wiki page of ISO 8601 is even worse: R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M
Certainly agree that the ISO format can be difficult for humans to read, both from the lack of spaces and terse syntax. This isn’t (much) of a problem from a display format perspective because we can parse the encoded format and present the user with a human readable version. So the readability issue is more about the encoded format. But unlike the display format, which could follow whatever grammar or locale preference of the user, the encoded format must be unambiguously parseable. If it’s possible to make the ISO format more human readable while still preserving parseability this could be viable. I’m less arguing against the option for encoding things in a variation of the ISO standard, but urging that Org support using an encoding of the ISO format in its raw state. > And we need to deviate from ISO 8601 anyway. At least, because it does > not define time zones, only absolute UTC offsets. So, the ability to > conform with the existing formats remains questionable. This is correct for the 2019 version of the ISO 8601. From my understanding the newest ISO draft is incorporating an existing syntax used in java.time.ZonedDateTime [JAVAZDT] to allow for time zones. So we could still aim for compliance with published standards. The Internet Extended Date/Time Format (IXDTF) is a forthcoming standard which defines an extension syntax for timestamps as specified in [RFC3339] which itself is compatible with the [JAVAZDT] syntax. The IXDTF is of particular interest in this situation because the format provides a general way to attach any additional information to a timestamp. The authors have done a great job of lucidly explaining some of the nuances of timestamps. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ > I will need more time to look through the provided links and think about > the ideas. Look forward to your comments!
