From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id kFcfF+pq02P5ngAAbAwnHQ (envelope-from ) for ; Fri, 27 Jan 2023 07:10:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id yO4tFupq02PrcAAAG6o9tA (envelope-from ) for ; Fri, 27 Jan 2023 07:10:50 +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 999EF37FEB for ; Fri, 27 Jan 2023 07:10:49 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLHwL-0005F5-Vi; Fri, 27 Jan 2023 01:10:22 -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 1pLHwK-0005Ej-F1 for emacs-orgmode@gnu.org; Fri, 27 Jan 2023 01:10:20 -0500 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pLHwE-0004K7-4f for emacs-orgmode@gnu.org; Fri, 27 Jan 2023 01:10:20 -0500 Received: by mail-wm1-x335.google.com with SMTP id d4-20020a05600c3ac400b003db1de2aef0so2675608wms.2 for ; Thu, 26 Jan 2023 22:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wakatara.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DyJyqY68526tXOn+fH4UBCEhDzK0fhBx/QP8DU6FaYg=; b=SBTcNEvGDze0issnkbP0Ht7DXKIAUbRp+uF0d/nbn1WeR+1O2KRUIIWcAXFCEC4kft EaRXvjjoNm4+Uw0FPuIeinche99Q3DgL/YOFYJ0EQcQhDuKUPTtlV6iKAOU1U/xdw//0 pL+wG36fS9CefLHibP8UkQ6pBVkAnT3l+rXcYnwxZ3ytaHC/exuFApHbQl1oiecY1dHS 8aWQn7ArS3Qfq6nYcBO3dwRO7mn4YrmJPcs5v0Yrvm9TjoI1rW9DDyw22nFKe7RoYZH6 aLuQhV/zXGzHW0tZYt4WxsYukNMXW08SnPkTA0+fDov+7s31sFZrmdora/RWvFOmczHi IKSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DyJyqY68526tXOn+fH4UBCEhDzK0fhBx/QP8DU6FaYg=; b=aPkSHPQFypgc4Wc8ZXZuvCI2R6iFkpsFiqHFDiyi/QWawRLC3iMZp/811QHgH/DnGa ryBE9++EoY75Q4AvUM4MjgwwP0FH1LVYZPcVJPlH1yIg/+7zCb27DWSYa8O/JiJp+0A4 8l4Lekt+aad74CsgjzG9wvbAppvCV5QxO6KWnL0i3HB1iPiAb5GzHVa81TYUGDZHoRma h176op69f6PATeULM+nikrb0OySg7eh0lXdCQXd9GN3P+WjX8MdhrBqyjeDYqxhCXMBM yguI7hpaG3gxWwdZfAx/ecvxBgzbUjxEoE/yKbriM5ykAUOOf4IeQT5dd4X/L4Ngv9mI k0dw== X-Gm-Message-State: AFqh2konap0Ffse2ZK/phbWJA3WPuTJryq89zt29YUAypbMY2U7IjjCh DhIWExAPN7ea8X8BotWF9UBdgPBsKUfR+vQ2kTPUog== X-Google-Smtp-Source: AMrXdXuDzOLmXtlmIxyvANFfTo/GFE3bVIR97zBKuVH+BVxIXbN5umCFSczCMW0/3O4aNflBW4OBNNoIFdNxuXrVhLY= X-Received: by 2002:a05:600c:3548:b0:3db:1d9b:9fd8 with SMTP id i8-20020a05600c354800b003db1d9b9fd8mr1596457wmq.157.1674799811140; Thu, 26 Jan 2023 22:10:11 -0800 (PST) MIME-Version: 1.0 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> <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> In-Reply-To: <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> From: Daryl Manning Date: Fri, 27 Jan 2023 13:09:34 +0700 Message-ID: Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda To: Sterling Hooten Cc: "Thomas S. Dye" , Tim Cross , Jean Louis , Ihor Radchenko , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="000000000000d0345505f338b774" Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=daryl@wakatara.com; helo=mail-wm1-x335.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, HTML_MESSAGE=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=1674799849; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=DyJyqY68526tXOn+fH4UBCEhDzK0fhBx/QP8DU6FaYg=; b=bCOfI2erWzmpm4bUEzWwsM21FqSiGw3dHdLkngoy1zgIJRWWMPK2SjV6irY4d2Ml8AYZXj eMQDvPjic+E0ZvhIbd1mMC7itUFVUklv/di+ok1YbXv06qs+VJpNxyEj1MAaSx4+Q/mNcx SByskEEUt1tZHzZRy1X7H4D7scKlN0wqqXWbFjk+esVcWka6UrOSlP2DdF1PdlY+NeKI0/ cFmFdrYQsihn44Ij7a57NjbhzWepDzBY/MI/n6tv1y2aZxMNKU8dsbKh7u3gJMhMd5i5Y7 J+lYZ1/fM8WaXwaYKi2VyUxgvgY0hMmVNGSyLidyvH85Ve9ibaBcJJeQjrlkJA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=wakatara.com header.s=google header.b=SBTcNEvG; dmarc=none; 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=1674799849; a=rsa-sha256; cv=none; b=jU6jMrGCo2IIpJPGip5t7DPOi8j8OrBZtLyN0e2BmQ9XyJ68vNZkMJzw8gUb3qr+UcWOMD 8KVSruQru4p49+sM7pBOWuRdT0xtDDdKwhZ2bMYXyDnZpYt+dEXUDtDRA8sryY6/27eMCY T9BtPQEyWaG77XURsszZXgfpkLv9aRQg4A7oThbyVMkjAQDF7M+9DZECF9Q5sriF4l9laX jzXdBZBwloj6xOQGojfSn1dzfoJnZ1rHj8Eqo2goGvhMD3I9TOcz34CHdOVuspUq19mcpz v+0QYN/Jn3fDdUQJucHKOqz39CWhLE+rCb1chz9d2ZTnJqIB3UYOkmfNXDqwXA== X-Spam-Score: -4.01 X-Migadu-Spam-Score: -4.01 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=wakatara.com header.s=google header.b=SBTcNEvG; dmarc=none; 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: 999EF37FEB X-Migadu-Scanner: scn1.migadu.com X-TUID: Kf5xFuJX9XHG --000000000000d0345505f338b774 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh wow... this is a great idea. Good idea sending it round. Ought to make things a bit easier when discussing and avoiding misunderstandings. =3D] On Fri, Jan 27, 2023 at 1:06 PM Sterling Hooten wrote: > 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-b= ased, > 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 i= s 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 t= hat 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 tim= estamps > 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/simp= le 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 expre= ssions > 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 lan= guage > 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 rat= her > than debate among ourselves > =E2=80=A2 Interfacing with other programs is simplified as the area ins= ide the > delimiter notation can be passed as a string without parsing. > =E2=80=A2 New users and collaborators can be onboarded faster without n= eeding > to learn a new system > =E2=80=A2 Org documentation can refer to the standard instead of bearin= g 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 > > --000000000000d0345505f338b774 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh wow... this is a great idea. Good idea sending it round= . Ought to make things a bit easier when discussing and avoiding misunderst= andings.=C2=A0 =3D]

On Fri, Jan 27, 2023 at 1:06 PM Sterling Hooten <= ;hooten@gmail.com> wrote:
Hi all,

Collaborating around the subject of "time" is difficult; there ar= e
subtleties abound in implementation, the perspectives people come from,
and the language used in discussions. I'm going to provide a glossary t= o
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 usefu= l
in articulating a possible road map forward.

=E2=80=A2 Time

=C2=A0 Time (concept)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 What clocks measure (Einstein)
=C2=A0 Time axis
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mathematical representation of the succession i= n time according
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the space-time model of instantaneous events= along a unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0 axis (ISO).

=C2=A0 Instant (object)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A single point on time axis (ISO).
=C2=A0 Moment in time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 See: instant.
=C2=A0 Mark
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A set of symbols related to the object, or carr= ying some
=C2=A0 =C2=A0 =C2=A0 =C2=A0 symbolic meaning
=C2=A0 Time scale
=C2=A0 =C2=A0 =C2=A0 =C2=A0 System of ordered marks which can be attributed= to instants on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the time axis , one instant being chosen as the= origin. e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 GMT, UTC, TAI.
=C2=A0 Basis time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 See: time scale.
=C2=A0 Time (mark)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The designation of an instant on a selected tim= e scale, used in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the sense of time of day.
=C2=A0 Time interval (object)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 part of the time axis limited by two instants a= nd, unless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 otherwise stated, the limiting instants themsel= ves a part of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time limited by two instants or moments in time= (ISO). The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 elapsed time between two events (NIST).
=C2=A0 Duration (object)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a quantity characterizing a time interval. T= hese can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 written in different formats.
=C2=A0 UTC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Time scale with the same rate as International = Atomic Time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (TAI), but differing from TAI only by an integr= al number of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 seconds.
=C2=A0 Offset
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Constant duration difference between times of t= wo time scales
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (ISO). i.e., a quantity to combine with a time = scale to produce
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a wall time. e.g., Nepal uses a +5:45 offset fr= om the UTC time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scale.
=C2=A0 Time shift
=C2=A0 =C2=A0 =C2=A0 =C2=A0 See: offset.
=E2=80=A2 Calendar and civil time
=C2=A0 Wall time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 what shows on the clock on the wall at a locati= on. Like "local
=C2=A0 =C2=A0 =C2=A0 =C2=A0 system time" but needn't reference a c= omputer to do the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 calculation.
=C2=A0 Standard time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Time scale derived from UTC, by a time shift es= tablished in a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 given location by the competent authority (ISO)= .
=C2=A0 Local system time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Local system time is determined by applying the= system's time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 zone offset and year offset values to UTC. The = Time of day
=C2=A0 =C2=A0 =C2=A0 =C2=A0 system value displays the local system time. Lo= cal system time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and system time are used interchangeably.
=C2=A0 Time Zone
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A place/region. Can map between wall time and a= time scale with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a table and an offset. A set of rules for deter= mining the local
=C2=A0 =C2=A0 =C2=A0 =C2=A0 observed time (wall time) as it relates to incr= emental time (as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used in most computing systems) for a particula= r geographical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 region. e.g., Bras=C3=ADlia time presently has = an offset of =E2=88=9203:00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 from the UTC time.
=C2=A0 Calendar event
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A calendar object that is commonly used to repr= esent things that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mark time or use time. Examples include meeting= s, appointments,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 anniversaries, start times, arrival times, clos= ing times.

=E2=80=A2 Implementation These concern how we actually decide to record, =C2=A0 reference, or manipulate time.
=C2=A0 Representation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Expression indicating a time point, time interv= al or recurring
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time interval. e.g., [2023-02-02 Thu 12:58 +1w]= , "this next
=C2=A0 =C2=A0 =C2=A0 =C2=A0 suday at 2pm EST", 3600 seconds from Unix = epoch
=C2=A0 Format
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A description of the abstract form used for a r= epresentation.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e.g., [YYYY-MM-DD] 'Explain in prose relati= ve to this moment in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time using locale and include your timezone'= ;
=C2=A0 Encoding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The method of storing a representation of time = e.g., datestruct
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in memory, Org timestamp in body of heading, va= lue of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "created" key in a database
=C2=A0 Format syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Rules that allow for parsing a encoding unambig= uously into some
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time scale.
=C2=A0 Timestamp (mark)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 An encoded representation in a selected format.= e.g., 24/01/2023
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or 2023-01-24
=C2=A0 Delimiting syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Rules that allow for detection and extraction o= f an encoding.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Necessary for encodings embedded in prose. e.g.= , '[]' for org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 timestamps.

=C2=A0 Displayed time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The formatting of a representation exposed to a= user.
=C2=A0 Calculating
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Manipulating a set of time points, time interva= ls, or recurring
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time intervals. e.g., determining instant from = an offset,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 comparing two representations in some lattice.<= br> =C2=A0 Incremental time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A datetime value consisting of monotonically in= creasing integer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 units measured from a specific moment in time (= epoch). For
=C2=A0 =C2=A0 =C2=A0 =C2=A0 example, the moment 1970-01-02T00:00:00.000Z mi= ght have an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 incremental time value (measured in millisecond= s) of 86400000,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 since there are 86,400 seconds in a day and 100= 0 ms in a second.
=C2=A0 Floating time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A wall time value without time zone or offset i= nformation. E.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2023-01-24 or 6:45pm.
=C2=A0 Fixed time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A representation of a (past or future) UTC time= .
=C2=A0 Absolute time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 See: fixed time.
=C2=A0 Unfixed time (from UTC)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A representation which is not referenced to a p= ast or future UTC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time. e.g., Future time given as a local time i= n some specified
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time zone, where changes to the definition of t= hat time zone
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.g., a political decision to enact or rescind= daylight saving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time) affect the instant in time corresponding = with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 timestamp.
=E2=80=A2 Time formats
=C2=A0 Incremental timestamp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Timestamps that can be directly compared: their= integer values
=C2=A0 =C2=A0 =C2=A0 =C2=A0 determine which is earlier or later. e.g., Unix= seconds since
=C2=A0 =C2=A0 =C2=A0 =C2=A0 epoch.
=C2=A0 Field-Based timestamp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Timestamps which must be normalized and their i= ndividual fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 compared. Field based times can have certain ki= nds of logical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 operations performed on them (for example, roll= ing the month
=C2=A0 =C2=A0 =C2=A0 =C2=A0 forward or back), while incremental time requir= es a logical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 transformation. e.g., ISO8601 style timestamps.=
=C2=A0 ISO Basic format
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A format which omits hyphen separators e.g., YY= YYMMDD
=C2=A0 ISO Extended format
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A format which includes hyphen separators e.g.,= YYYY-MM-DD
=C2=A0 Extended Date/Time Format EDTF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 An extension of the ISO 8601 created by the Lib= rary of Congress
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to cover date formats and conditions useful in = metadata systems
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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-bas= ed,
=C2=A0 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)
=C2=A0 =E2=80=A2 This is referring to an unambiguous moment in time
=C2=A0 =E2=80=A2 e.g., 2007-02-03T05:00:00.000Z
=E2=80=A2 Offset (fixed)
=C2=A0 =E2=80=A2 This captures the idea of "when did it happen for the= person who
=C2=A0 =C2=A0 made the observation"
=C2=A0 =E2=80=A2 e.g., 2007-02-03T04:00:00.000+01:00
=E2=80=A2 Instant with explicit offset and zone (fixed)
=C2=A0 =E2=80=A2 e.g., 2007-01-01T02:00:00.000+01:00[America/Chicago]
=E2=80=A2 Zoned local date time (floating)
=C2=A0 =E2=80=A2 Tricky, requires decisions about how to interpret timestam= ps after
=C2=A0 =C2=A0 political changes.
=C2=A0 =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
=C2=A0 =E2=80=A2 Decide on a time scale
=C2=A0 =E2=80=A2 Decide on a format and syntax
=C2=A0 =E2=80=A2 Implement instant timestamps
=C2=A0 =E2=80=A2 Implement offeset timestamps
=E2=80=A2 Design and implement the time zone aware calendar system This is = a
=C2=A0 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<= br> 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)]<= br> 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 f= rom
=C2=A0 an ISO date Any user who wishes to display a format with the day of<= br> =C2=A0 the week can do so.
=E2=80=A2 It's a nonstandard format Although the Org documentation says= that the
=C2=A0 timestamps are "inspired by the standard ISO 8601 date/time for= mat"
=C2=A0 the use of a day name is not contained in the ISO specification. The=
=C2=A0 present Org format is actually two ISO components, the date and the<= br> =C2=A0 time, with a non-standard day name sandwiched between them with spac= e
=C2=A0 separators. Spaces are no longer allowed in the ISO format. By
=C2=A0 deviating from an existing standard we place the burden of parsing o= n
=C2=A0 ourselves and make sharing more difficult.
=E2=80=A2 Day of the week is irrelevant in many situations Looking at times= tamps
=C2=A0 from a year ago it's often the case that what day of the week it= was
=C2=A0 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
=C2=A0 floating timestamp This simplifies the issues of maintaining
=C2=A0 compatibility with existing org documents. It also placates those wh= o
=C2=A0 have single user systems in a single time zone who do not want to ha= ve
=C2=A0 any calendar complexity imposed on them.
=E2=80=A2 We have a way of distinguishing new timestamps from legacy/simple= ones
=C2=A0 By making a change in syntax we reduce (or eliminate?) the possibili= ty
=C2=A0 of ambiguity between "which version" of a timestamp is bei= ng parsed. A
=C2=A0 legacy timestamp can be treated as such, and new timestamps are easi= ly
=C2=A0 identified by the 'T' present instead of spaces, or in the d= elimiters
=C2=A0 wrapping the representation.
=E2=80=A2 We free ourselves from the constraints of the legacy timestamp fo= rmat
=C2=A0 Trying to engineer a new syntax which also parses as an extension of=
=C2=A0 the legacy one is more complex and embeds things like "day of t= he
=C2=A0 week" and the use of spaces as separators into this new system.= Easier
=C2=A0 to have two side by side.
=E2=80=A2 We can defer to existing parsing and calculating systems There ar= e
=C2=A0 already programs written which support the ISO standard and EDTF. =C2=A0 =E2=80=A2 We can directly (or nearly directly) import the regular ex= pressions
=C2=A0 =C2=A0 and parsing mechanisms already written.
=C2=A0 =E2=80=A2 These enable decent testing suites as we build the system,= as we can
=C2=A0 =C2=A0 check against existing packages to see if our parsing and
=C2=A0 =C2=A0 calculations agree.
=C2=A0 =E2=80=A2 Users who wish to use external libraries (irrespective of = language
=C2=A0 =C2=A0 or license) can extract the new timestamp and parse or calcul= ate
=C2=A0 =C2=A0 externally.
=E2=80=A2 Org is part of a standard
=C2=A0 =E2=80=A2 We are able to defer to experts and 35 years of knowledge = rather
=C2=A0 =C2=A0 than debate among ourselves
=C2=A0 =E2=80=A2 Interfacing with other programs is simplified as the area = inside the
=C2=A0 =C2=A0 delimiter notation can be passed as a string without parsing.=
=C2=A0 =E2=80=A2 New users and collaborators can be onboarded faster withou= t needing
=C2=A0 =C2=A0 to learn a new system
=C2=A0 =E2=80=A2 Org documentation can refer to the standard instead of bea= ring the
=C2=A0 =C2=A0 burden of exposition.
=E2=80=A2 The move to include time zones in the format is simplified
=C2=A0 =E2=80=A2 The ISO standard has recently adopted a format for time zo= nes from
=C2=A0 =C2=A0 RFC3339 and JAVAZDT, we can adhere to 8601 and keep things =C2=A0 =C2=A0 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 pos= sibly
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
=C2=A0 =E2=80=A2 ical standard
=C2=A0 =E2=80=A2 CalConnect standard
=C2=A0 =E2=80=A2 Thunderbird/lightning calendar
=C2=A0 =E2=80=A2 Google calendar
=C2=A0 =E2=80=A2 Outlook
=C2=A0 =E2=80=A2 Lotus notes
=E2=80=A2 Standard organizations
=C2=A0 =E2=80=A2 NIST
=C2=A0 =E2=80=A2 ISO
=E2=80=A2 Database or computer applications
=C2=A0 =E2=80=A2 SQL
=C2=A0 =E2=80=A2 Oracle
=C2=A0 =E2=80=A2 Java's time system
=C2=A0 =E2=80=A2 Numpy
=C2=A0 =E2=80=A2 Rust
=E2=80=A2 Archival or research users
=C2=A0 =E2=80=A2 Library of congress
=C2=A0 =E2=80=A2 Metadata systems
=E2=80=A2 Academic users
=C2=A0 =E2=80=A2 History
=E2=80=A2 Scientific users
=C2=A0 =E2=80=A2 Astronomers
=C2=A0 =E2=80=A2 Physicists
=C2=A0 =E2=80=A2 Chemists
=C2=A0 =E2=80=A2 Geologists
=C2=A0 =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 exp= anded
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:8= 601:-1:ed-1:v1:en
https://www.w3.org/International/articles= /definitions-time/
https://www.ibm.com/docs/en/i/7.3?topic=3Dcon= cepts-time
https://tc39.es/proposal-temporal/docs/ambiguit= y.html

EDTF

https://www.loc.gov/standards/datetime/ Main page on EDTF=
https://edtf.wikibase.wiki/wiki/Property:P1 Has examp= les of EDTF codes
https://www.wikibase.consulting/wikibase-edtf/ Wik= ibase implemented
EDTF in 2021
https://github.com/ProfessionalWiki/Wi= kibaseEdtf#wikibase-edtf
https://github.com/corylown/edtf-humanize Transform EDT= F strings into
human friendly display https://github.com/unt-librarie= s/edtf-validate
Validate EDTF strings https://github.com/plk/biblatex/issu= es/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 Parse= r for EDTF

Implemention details

https://www.w3.org/TR/international-specs/#loc_ti= me
https://dev.mysql.com/doc/refm= an/5.7/en/date-and-time-type-syntax.html

Time zones

https://datatracker.ietf.org/do= c/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 re= levant
https://www.w3.org/International/= core/2005/09/timezone.html#IDALFAT

Calendar and scheduling

https://www.calconnect.org/resources/glossary

--000000000000d0345505f338b774--