From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id wEYAEhlq02MaVAEAbAwnHQ (envelope-from ) for ; Fri, 27 Jan 2023 07:07:21 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id AHj9ERlq02PieQAA9RJhRA (envelope-from ) for ; Fri, 27 Jan 2023 07:07:21 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B92D928D1D for ; Fri, 27 Jan 2023 07:07:19 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLHsT-00042r-2y; Fri, 27 Jan 2023 01:06:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLHsR-00042S-AX for emacs-orgmode@gnu.org; Fri, 27 Jan 2023 01:06:19 -0500 Received: from mail-oa1-x2a.google.com ([2001:4860:4864:20::2a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pLHsO-0003WG-8j for emacs-orgmode@gnu.org; Fri, 27 Jan 2023 01:06:19 -0500 Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-16346330067so5274653fac.3 for ; Thu, 26 Jan 2023 22:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=d16O/whiFlNFKyvi8eBeJ4rau3zNt1qd4cr6zglielU=; b=lLst6JrBp+LyEi5zhDh5eMq6tVKnkiTnXVrEtNjWZ5RqjvihXGvfCO24OYQ+cW8oZq uuMhQXXMOXx5TJpkP1Yv/rzv0H0OONFwYASisCMqvEQQVCxjZDJZm0N7nkNWT/eBe6Fa 0XA4q2ftDcRI3qaTCR9SS4lpPsZdFaZq/EckiR12v9JQQZ2nkFRaqN7e5/7FqHCCoXcm AaUtmXBbURjw2EWtjNBM+OCG9RniooudCN4wOJBPAI8716EHhs0bYZ9Jjyr1af4JtWFQ QqcmWUdHjVv0yXhGY0XSdHLH13enHT9eOyIMxtGpHLa69JXbBSq/x+fwXldr8drtTCEL l9/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=d16O/whiFlNFKyvi8eBeJ4rau3zNt1qd4cr6zglielU=; b=TYOVYW3VJyWvmWBKBvBuWgH04uVe7iQ/KLnhMe4LRy6mAgvpID9RCyl48xYNxGV+SF cGoWTse85drrfroDQl0SPE1i0iD6cIET0l7keLahtIMjRkV231narVv5zrBQwQ6lCvW5 H6xjJJX5quGe+L24/YHWb6tlsuOw+EpNZC9a7rolFksRnHFXVObRV/MaadyCObwGUKT1 C5454N/DSnTyQMTbEFwanKXxxLXYJxSLPy9IWaOQ++pbT1YrUZi7XbsGnE88sGa3qY6P +lg0AC2SjDWcJaru0gl2SLratbxEHLWu8TpkpC6joXGDPC0wYoxrB++5/bKHOC+uSyNt JiBQ== X-Gm-Message-State: AFqh2kq8hs+4R3cv9RfKg32cMxXfxrdbnhD0q/F2WBdd1jVq/nXXA85Q Iip6p4MpQWq3+wf7axs6niQ= X-Google-Smtp-Source: AMrXdXvcT9jc5jPtw5QhZLHCyJ2ns3FkGYXtCJG5Vle77sYxSkDyqEhix7nB7/tEsrFRXbBMlu7NHg== X-Received: by 2002:a05:6870:c994:b0:15e:d799:b39e with SMTP id hi20-20020a056870c99400b0015ed799b39emr20560991oab.56.1674799574051; Thu, 26 Jan 2023 22:06:14 -0800 (PST) Received: from smtpclient.apple ([2804:14c:116:8fc3:406b:c7fc:7000:4d00]) by smtp.gmail.com with ESMTPSA id k26-20020a4ad11a000000b004f29c6fb6besm1319262oor.31.2023.01.26.22.06.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2023 22:06:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda From: Sterling Hooten In-Reply-To: <87pmb9k8oi.fsf@tsdye.online> Date: Fri, 27 Jan 2023 03:06:08 -0300 Cc: Tim Cross , Jean Louis , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> References: <63c66048.630a0220.427bf.a5f6@mx.google.com> <87r0vtiks0.fsf@localhost> <63c671c0.a70a0220.61aa5.56b8@mx.google.com> <87fsc88aq9.fsf@localhost> <63c7dd3d.170a0220.6b4d6.f84f@mx.google.com> <877cxk6oeu.fsf@localhost> <63c86454.170a0220.80970.652d@mx.google.com> <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> <63c9b654.170a0220.d82d2.4254@mx.google.com> <87mt6e86sr.fsf@tsdye.online> <63c9d976.620a0220.a7d40.113b@mx.google.com> <87tu0mjb24.fsf@tsdye.online> <63ca1283.170a0220.5bc81.0fdd@mx.google.com> <87pmb9k8oi.fsf@tsdye.online> To: "Thomas S. Dye" X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2001:4860:4864:20::2a; envelope-from=hooten@gmail.com; helo=mail-oa1-x2a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674799640; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=d16O/whiFlNFKyvi8eBeJ4rau3zNt1qd4cr6zglielU=; b=LCgCWsRct1ZNMTroWqeC2o3K2p97UEghuJMxYReNZ3e8aBQ9iifkwe+NlDzEtljsSYpDKj CPiiB5PYIBYPV5BAITzhJqaqNMKNf2fOSt/84mKDgc3JAy2+sVfhVVhuY3fW26XJ4OxbEU W/Fy/rvpm6okuzH4l12J+sk+y81V010JtWXGWxcO9ryqBbILXkA7g7KrdwxgH7SUnSB4b8 +6F7/jwNDVQUisxQAzdIJKSsqCEMqKkwegU6bVRG19Pom6wPRAKBGKFN21G7JcEECQrq+H 9XcEEvkO8VvPo/p0kKgKGH+s83hU/J/7HWdOt0ms1e0tuez81qg+8uF70YwzpA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lLst6JrB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1674799640; a=rsa-sha256; cv=none; b=IVLamQpp95p2wu3LXRYI8ZSVpyfqaWhVScdf/INNCKfYf+cC4nE9MvhJIEshPzWSNxwMiJ G5O3qjvYVLeaZgyQt6BnSUC0XutGRmYcxsqLlq5WeVSViYhSg7iZFtrLXSYVz/LSafQ928 UgE/vpacgvfjPgZbGzjPl0t3mWmmPqyoBJX8EmpBijbJKLJ5Z4+0wCX1jwAZ+TjXay7+Us 4s43TCozbUaO/2HRgGTgLM7Nt1JVZlbGKdvagcli5EJiXyk3ixPamV+zWWJVp7F9HE+nEm w6HcXi5bt9XMUkucaNDmE8eygxEU01PsIalj9HBoSx11p3oB1wQwoTi3bp2PgQ== X-Spam-Score: -4.25 X-Migadu-Spam-Score: -4.25 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lLst6JrB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: B92D928D1D X-Migadu-Scanner: scn1.migadu.com X-TUID: LHYEOaFFOGjp Hi all, Collaborating around the subject of "time" is difficult; there are subtleties abound in implementation, the perspectives people come from, and the language used in discussions. I'm going to provide a glossary to establish common terminology, use these terms to analyze our current state, offer a roadmap for solving the problem in stages, suggest a format for timestamps, urge compatibility with "exotic" use cases, and finally call for outside help with implementing a timezone aware agenda system. Summary and references are at the end. This is an initial glossary compiled from various standards and sources; it's incomplete, probably incorrect, and open to critique, but is useful in articulating a possible road map forward. =E2=80=A2 Time Time (concept) What clocks measure (Einstein) Time axis Mathematical representation of the succession in time according to the space-time model of instantaneous events along a unique axis (ISO). Instant (object) A single point on time axis (ISO). Moment in time See: instant. Mark A set of symbols related to the object, or carrying some symbolic meaning Time scale System of ordered marks which can be attributed to instants on the time axis , one instant being chosen as the origin. e.g., GMT, UTC, TAI. Basis time See: time scale. Time (mark) The designation of an instant on a selected time scale, used in the sense of time of day. Time interval (object) part of the time axis limited by two instants and, unless otherwise stated, the limiting instants themselves a part of time limited by two instants or moments in time (ISO). The elapsed time between two events (NIST). Duration (object) as a quantity characterizing a time interval. These can be written in different formats. UTC Time scale with the same rate as International Atomic Time (TAI), but differing from TAI only by an integral number of seconds. Offset Constant duration difference between times of two time scales (ISO). i.e., a quantity to combine with a time scale to produce a wall time. e.g., Nepal uses a +5:45 offset from the UTC time scale. Time shift See: offset. =E2=80=A2 Calendar and civil time Wall time what shows on the clock on the wall at a location. Like "local system time" but needn't reference a computer to do the calculation. Standard time Time scale derived from UTC, by a time shift established in a given location by the competent authority (ISO). 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. Time Zone A place/region. Can map between wall time and a time scale with a table and an offset. A set of rules for determining the local observed time (wall time) as it relates to incremental time (as used in most computing systems) for a particular geographical region. e.g., Bras=C3=ADlia time presently has an offset of = =E2=88=9203:00 from the UTC time. Calendar event A calendar object that is commonly used to represent things that mark time or use time. Examples include meetings, appointments, anniversaries, start times, arrival times, closing times. =E2=80=A2 Implementation These concern how we actually decide to record, reference, or manipulate time. Representation Expression indicating a time point, time interval or recurring time interval. e.g., [2023-02-02 Thu 12:58 +1w], "this next suday at 2pm EST", 3600 seconds from Unix epoch Format A description of the abstract form used for a representation. e.g., [YYYY-MM-DD] 'Explain in prose relative to this moment in time using locale and include your timezone' Encoding The method of storing a representation of time e.g., datestruct in memory, Org timestamp in body of heading, value of a "created" key in a database Format syntax Rules that allow for parsing a encoding unambiguously into some time scale. Timestamp (mark) An encoded representation in a selected format. e.g., 24/01/2023 or 2023-01-24 Delimiting syntax Rules that allow for detection and extraction of an encoding. Necessary for encodings embedded in prose. e.g., '[]' for org timestamps. Displayed time The formatting of a representation exposed to a user. Calculating Manipulating a set of time points, time intervals, or recurring time intervals. e.g., determining instant from an offset, comparing two representations in some lattice. Incremental time A datetime value consisting of monotonically increasing integer units measured from a specific moment in time (epoch). For example, the moment 1970-01-02T00:00:00.000Z might have an incremental time value (measured in milliseconds) of 86400000, since there are 86,400 seconds in a day and 1000 ms in a second. Floating time A wall time value without time zone or offset information. E.g., 2023-01-24 or 6:45pm. Fixed time A representation of a (past or future) UTC time. Absolute time See: fixed time. Unfixed time (from UTC) A representation which is not referenced to a past or future UTC time. e.g., Future time given as a local time in some specified time zone, where changes to the definition of that time zone (e.g., a political decision to enact or rescind daylight saving time) affect the instant in time corresponding with the timestamp. =E2=80=A2 Time formats Incremental timestamp Timestamps that can be directly compared: their integer values determine which is earlier or later. e.g., Unix seconds since epoch. Field-Based timestamp Timestamps which must be normalized and their individual fields compared. Field based times can have certain kinds of logical operations performed on them (for example, rolling the month forward or back), while incremental time requires a logical transformation. e.g., ISO8601 style timestamps. ISO Basic format A format which omits hyphen separators e.g., YYYYMMDD ISO Extended format A format which includes hyphen separators e.g., YYYY-MM-DD Extended Date/Time Format EDTF An extension of the ISO 8601 created by the Library of Congress to cover date formats and conditions useful in metadata systems but not handled in the ISO standard. What does format does Org have now? =E2=80=A2 The format currently in use for timestamps is floating, = field-based, and has a resolution/precision of minutes. What kinds of representations would a calendar system capable of handling timezones require? =E2=80=A2 Instant (fixed) =E2=80=A2 This is referring to an unambiguous moment in time =E2=80=A2 e.g., 2007-02-03T05:00:00.000Z =E2=80=A2 Offset (fixed) =E2=80=A2 This captures the idea of "when did it happen for the person = who made the observation" =E2=80=A2 e.g., 2007-02-03T04:00:00.000+01:00 =E2=80=A2 Instant with explicit offset and zone (fixed) =E2=80=A2 e.g., 2007-01-01T02:00:00.000+01:00[America/Chicago] =E2=80=A2 Zoned local date time (floating) =E2=80=A2 Tricky, requires decisions about how to interpret timestamps = after political changes. =E2=80=A2 e.g., 2007-01-01T01:00:00.000[America/Chicago] I claim that before dealing with the nuances of calendar appointments, repeating events, agenda displays etc, that Org must first support fixed/absolute time instead of just floating time. Without some basis time scale the conversions from time zones and offsets to some incremental time point is impossible. Resolving this prerequisite will also simplify the timezone discussion because we won't be mixing calendar issues with time issues. What would a roadmap be? =E2=80=A2 Design and implement an absolute and offset timestamp system =E2=80=A2 Decide on a time scale =E2=80=A2 Decide on a format and syntax =E2=80=A2 Implement instant timestamps =E2=80=A2 Implement offeset timestamps =E2=80=A2 Design and implement the time zone aware calendar system This = is a separate project. What time scale should Org use? There are only two decent options, either TAI or UTC. The rest of the world has agreed upon UTC, we should too. Conversion to TAI can be done by users or on export. What format and syntax should Org use? A heretical suggestion: We should abandon the day of week abbreviation and use a new format. The current format generates a three leter abbreviation of the day of the week [2023-01-25 Wed 12:12]. I suggest supporting this as a legacy/simple format but switch to a format/encoding like [2023-01-25T15:13:42Z] for the new system. Specifically I'm advocating for an extended ISO 8601 format, compatible with expanded dates and Level 2 of the EDTF, with some (bracket?) notation surrounding it such that Org can parse the syntax as a timestamp. I advocate further for the use of durations and repeating intervals to follow the same standard format. Thus instead of a range being formatted as: [2023-01-25 Wed 13:57]=E2=80=93[2023-01-26 Thu 13:57] it would be: [2023-01-25T16:57:42Z/2023-01-26T16:57:42Z]. If the square bracket delimiter syntax is insufficient or too difficult to parse unambiguously, we could just encapsulate the ISO format in a sub-syntax (e.g., [&&(ISO format)] similar to the [%%(diary sexp)] technique). This is ugly, but perhaps a stepping stone during development to separate syntax parsing concerns from calculating etc. What are the problems with the day of the week in existing format? =E2=80=A2 The day of the week is redundant information and can be = rebuilt from an ISO date Any user who wishes to display a format with the day of the week can do so. =E2=80=A2 It's a nonstandard format Although the Org documentation says = that the timestamps are "inspired by the standard ISO 8601 date/time format" the use of a day name is not contained in the ISO specification. The present Org format is actually two ISO components, the date and the time, with a non-standard day name sandwiched between them with space separators. Spaces are no longer allowed in the ISO format. By deviating from an existing standard we place the burden of parsing on ourselves and make sharing more difficult. =E2=80=A2 Day of the week is irrelevant in many situations Looking at = timestamps from a year ago it's often the case that what day of the week it was created is unimportant. What are the advantages of switching to a standard format for the new system? =E2=80=A2 We can allow the legacy/simple system to coexist and interpret = it as a floating timestamp This simplifies the issues of maintaining compatibility with existing org documents. It also placates those who have single user systems in a single time zone who do not want to have any calendar complexity imposed on them. =E2=80=A2 We have a way of distinguishing new timestamps from = legacy/simple ones By making a change in syntax we reduce (or eliminate?) the possibility of ambiguity between "which version" of a timestamp is being parsed. A legacy timestamp can be treated as such, and new timestamps are easily identified by the 'T' present instead of spaces, or in the delimiters wrapping the representation. =E2=80=A2 We free ourselves from the constraints of the legacy timestamp = format Trying to engineer a new syntax which also parses as an extension of the legacy one is more complex and embeds things like "day of the week" and the use of spaces as separators into this new system. Easier to have two side by side. =E2=80=A2 We can defer to existing parsing and calculating systems There = are already programs written which support the ISO standard and EDTF. =E2=80=A2 We can directly (or nearly directly) import the regular = expressions and parsing mechanisms already written. =E2=80=A2 These enable decent testing suites as we build the system, = as we can check against existing packages to see if our parsing and calculations agree. =E2=80=A2 Users who wish to use external libraries (irrespective of = language or license) can extract the new timestamp and parse or calculate externally. =E2=80=A2 Org is part of a standard =E2=80=A2 We are able to defer to experts and 35 years of knowledge = rather than debate among ourselves =E2=80=A2 Interfacing with other programs is simplified as the area = inside the delimiter notation can be passed as a string without parsing. =E2=80=A2 New users and collaborators can be onboarded faster without = needing to learn a new system =E2=80=A2 Org documentation can refer to the standard instead of = bearing the burden of exposition. =E2=80=A2 The move to include time zones in the format is simplified =E2=80=A2 The ISO standard has recently adopted a format for time = zones from RFC3339 and JAVAZDT, we can adhere to 8601 and keep things consistent. What other perspectives should the new format support? In addition to the representations necessary for a timezone aware calendar system, I suggest the new format be compatible with two other representations: finer/ arbitrary resolution for scientific work, and Level 2 of the Extended Date/Time Format for bibliographic and metadata systems. Although most implementations come from the computer/database perspective, where precision is limited by clock speed, scientific data may be finer grained. Adopting a format which allows for arbitrary precision enables Org to be useful in more scenarios. This would allow data of higher frequency to be collected and stored into org headings as a plain text database. Even if the data was stored externally it would be convenient to be able to comment or discuss collected data by referencing its time point. The Extended Data/Time Format (EDTF) was designed by the Library of Congress to address limitations of the ISO standard for metadata and archival purposes. A draft specification was created in 2012 and EDTF functionality has now been integrated into ISO 8601-2019. Of great interest is the ability to express the concepts of uncertainty and approximation. Archival work includes scenarios where the precise date may be unknown, so a format was created with qualifiers capable of handling these situations. In the EDTF format '1984?' expresses possibly the year 1984, but not definitely, while '2004-06~' expresses year-month approximate. This format has been implemented by multiple library systems and in 2021 Wikibase added an extension to support EDTF. The initial technical or code burden to support these perspectives is minimal. Both can be parsed and calculated with by existing libraries, and the functionality to actually calculate with them can be delayed. The important thing is selecting a format which won't exclude them. That these features are omitted in many systems as result of the restricted domain and the data types used for storage; Org does not have these constraints. Further, both of these communities tend to attract people who are talented and sympathetic with (even occasionally funded to support!) open source projects. By expanding Org's format to be more inclusive we provide a haven rather than shutting them out. The calendar implementation should elicit help from experts Everyone seems in agreement that leveraging existing libraries is desirable. We should also read and defer to documentation and recommendations available from legitimate projects (e.g., W3, ISO). But I think these are still insufficient for architecting an elegent time system capable of satisfying the various perspectives. Calendar applications in particular contain many edge cases and decisions about display and interface etc. The knowldege concerning these is more likely tacit than explicit, so I suggest we reach out to people who have already designed/engineered solutions and get their input. Here are some projects, organizations, or perspectives we could seek help from: =E2=80=A2 Calendar applications =E2=80=A2 ical standard =E2=80=A2 CalConnect standard =E2=80=A2 Thunderbird/lightning calendar =E2=80=A2 Google calendar =E2=80=A2 Outlook =E2=80=A2 Lotus notes =E2=80=A2 Standard organizations =E2=80=A2 NIST =E2=80=A2 ISO =E2=80=A2 Database or computer applications =E2=80=A2 SQL =E2=80=A2 Oracle =E2=80=A2 Java's time system =E2=80=A2 Numpy =E2=80=A2 Rust =E2=80=A2 Archival or research users =E2=80=A2 Library of congress =E2=80=A2 Metadata systems =E2=80=A2 Academic users =E2=80=A2 History =E2=80=A2 Scientific users =E2=80=A2 Astronomers =E2=80=A2 Physicists =E2=80=A2 Chemists =E2=80=A2 Geologists =E2=80=A2 Metrologists To summarize: Org presently only supports simple floating timestamps. A calendar system capable of handling time zones requires some form of fixed or incremental timestamp with offsets. We can solve the absolute timestamp system first, and deal with calendar concerns after. If we're implementing a new time system the format and syntax should allow for "exotic" use cases like arbitrary precision, uncertainty, and expanded dates. The mechanics for calculating with those exotic cases needn't be implemented by Org immediately. We should adopt UTC as the time scale, EDTF (an extension of ISO 8601) as the time format, and merely encapsulate this format with a delimiting syntax (using brackets if possible) that Org can parse and distinguish from the present format. The existing Org format should be considered simple/legacy and can be interpretted or translated internally into the new system as calculations require. The new format can be implemented alongside the simple/legacy system. This discussion of absolute offset timestamps should be split off from timezone, calendar, and display concerns. Implementing a calendar application with timezones is complicated and we should seek help from those who have built the systems from before. References: Time https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en https://www.w3.org/International/articles/definitions-time/ https://www.ibm.com/docs/en/i/7.3?topic=3Dconcepts-time https://tc39.es/proposal-temporal/docs/ambiguity.html EDTF https://www.loc.gov/standards/datetime/ Main page on EDTF https://edtf.wikibase.wiki/wiki/Property:P1 Has examples of EDTF codes https://www.wikibase.consulting/wikibase-edtf/ Wikibase implemented EDTF in 2021 https://github.com/ProfessionalWiki/WikibaseEdtf#wikibase-edtf https://github.com/corylown/edtf-humanize Transform EDTF strings into human friendly display https://github.com/unt-libraries/edtf-validate Validate EDTF strings https://github.com/plk/biblatex/issues/656 Discussion of Biblatex's implementation of EDTF https://www.npmjs.com/package/edtf Parser for EDTF https://github.com/inukshuk/edtf.js/tree/main Parser for EDTF Implemention details https://www.w3.org/TR/international-specs/#loc_time https://dev.mysql.com/doc/refman/5.7/en/date-and-time-type-syntax.html Time zones https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ An extension syntax for representing time zone. We should follow this. Very helpful for implementing time zones. https://www.w3.org/TR/timezone/#representing Very relevant https://www.w3.org/International/core/2005/09/timezone.html#IDALFAT Calendar and scheduling https://www.calconnect.org/resources/glossary