From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 wKNMIg8h5mNoLwAAbAwnHQ (envelope-from ) for ; Fri, 10 Feb 2023 11:48:47 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id qAE+Ig8h5mN9NwAAauVa8A (envelope-from ) for ; Fri, 10 Feb 2023 11:48:47 +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 1FFEA8C38 for ; Fri, 10 Feb 2023 11:48:47 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQQwg-00041c-QD; Fri, 10 Feb 2023 05:47:58 -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 1pQQwd-0003zW-Lg for emacs-orgmode@gnu.org; Fri, 10 Feb 2023 05:47:55 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQQwb-0001gX-5B for emacs-orgmode@gnu.org; Fri, 10 Feb 2023 05:47:55 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 122362401F0 for ; Fri, 10 Feb 2023 11:47:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1676026071; bh=fwRuSofPkjiSMSWMyFv0YoN8wF1dHudEnOdJCCXe0cw=; h=From:To:Cc:Subject:Date:From; b=DBZw2ZhnveDlc2dlpV3djHF/7hhOtAjepX++j4b8U0uNjUyMELaVRdy4Zx3PuZJdM kwkQ3Sr+kfTroIQCTPb8UQeoyKslDUvn2lRvQKv62rK/nBexijp/6w3DgnV0r8KuiE I5HO6WidCkt17ohXNQIA2nVdsPmIwXHZU5O5DGVnjFGUecr3W3vwcjmsV3sNRrLk3q QtVmdVSD8oAVVYKXzfdP1iAplUkrwVcw/1tsEX2GwsvPVmtPXO+5VFe5emDhr3bqsz KieegReP/670jH00E6pt1HqJGtJD28P4I1dJagnZs8j8Qmgj+4rUb6xkvLkm5qC4Ct OYmjJAth1lp8Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PCr6Q1Bvgz6tnZ; Fri, 10 Feb 2023 11:47:41 +0100 (CET) From: Ihor Radchenko To: Jean Louis Cc: Ypo , Org-mode Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) In-Reply-To: References: <87lelce6iu.fsf@localhost> <87357i9959.fsf@localhost> <877cwse95m.fsf@localhost> Date: Fri, 10 Feb 2023 10:48:15 +0000 Message-ID: <878rh5eqz4.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, 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=1676026127; 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=j5me2rWXjhfQKtJ+J/G4mFFD6qwKU9KEl94ly7EoiaI=; b=W3NJsLam1PvB71TKTlQ04lvismRx45b5qgeg9hZ45Ut85XSPiLqXNwpvgh6b+cplArhdGX rgE37fmQ/t9f/WKpAfGVnjXzLvNci4Bom0h/Cc1IEkEhlRCQpouARb/bv+xeC+6zEFuQtX Qa2LSyhpd+1lOeghwPTHSQ+7ZALrQsZ0OnMWI+wO+HnCQJfR/EL+Fv2TlIlaBi1lbgDdbT gcDtr02KURGtScuLFMw+7RP5omWxZUCbuA5+9585WOKPQMJtUchJkv2AZwf4ElKFMSBlEi g8e6fmcbwT75PxNhHEqFz8Se8bOIq24lCm0bMzmn3dVA+lrzbIeT87X0d0RKFw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=DBZw2Zhn; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1676026127; a=rsa-sha256; cv=none; b=tyhIqgKVsSEvlBHD5vXRHpONvob1xTtM/Ehpi3d8+q9gKGw6oabewdgee4vXwwe4f4qmYJ LXnuUDPMhE2sK1PYEzmryNs++FRr8Gs4lNiICqJBfHkW06ekzCMD9cgyPFpye2++lLKc3w khlp92uHJTLAHEG/kMtZ1BOcwsx59X6CPclCsmFDr8JA99KL/qJBE4KJpFNm+WsUT9evuH QFESh4SDV8Or/qHf4n8apOzZx68ReTd09/IzOVr54I5BAkccioGD7WIYibAx3qh4A6GVhI 1lx85xlHwC71RNo1cGpdpivuZKWpFIgercKOzJiMZThP+noYzyjqIuVOnRT3HA== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -6.07 X-Spam-Score: -6.07 X-Migadu-Queue-Id: 1FFEA8C38 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=DBZw2Zhn; 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"; dmarc=pass (policy=none) header.from=posteo.net X-TUID: xZbVd77mI4fU Jean Louis writes: > If you start adding in Org "fixed" time with UTC offset, that is a new > type of timestamp, as it is not common in world. It is how ISO8601 defines offsets. > Here is suggestion: > ------------------- > > 1. Convert local time timestamp to UTC > 2. Add 10024 hours > 3. Provide timestamp in UTC This will involve converting time, which is prone to errors. I still think that sometimes it is more convenient for human to use familiar time zone and fix the offset for future. > Also look at this reference: > https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html > > ,---- > | The form of date and time with UTC offset MUST NOT be used. For > | example, the following is not valid for a DATE-TIME value: > | > | 19980119T230000-0800 ;Invalid time format > `---- > As with the above format, author would maybe think it is alright, but > in general it is confusing. If author wish to specify UTC time, then > no offset shall be used. icalendar is _not_ the only time spec around. We can take it into account, but I do not see any reason to follow it blindly. Reading the linked RFC spec, I did note that the motivation for the time format used in calendar is mainly scheduling meetings for people residing in different time zones. I can see how the icalendar format is reasonable within that specific purpose. I cannot see why Org timestamps should be limited to meetings. Note that the idea with (optionally) providing two time zones/offsets is also coming from a time spec in https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ Considering that the idea with "!" has been independently proposed within the current discussion, I assess that allowing two time zones can be useful. Please remember that this format is optional. If it is not useful for your use cases, feel free to specify a single time zone. >> I would like to remind you that timestamps are not necessarily used for >> meetings. And not always shared with other people. > > Ok, and I have asked you to provide practical examples. And I did, in one of the previous replies - scientific experiment. Another example can be solar eclipse. > Timestamps for past time, like for logs, I always store as UTC time in > database, with time zone (which does not mean that time zone is > stored, but displayed in local time zone). For Org, the aim is not to rely solely on programmatically calculating time in current time zone. It should be possible to create timestamps readable in raw text. UTC may be readable for some people, but not for others. Of course, you can put UTC timestamps in your files, if you prefer. But more general timestamp format should permit different use cases. > 1. [2024-02-04 12:00 @-08,America/Vancouver] you define that @-08 has > priority, OK fine, but how does user sees that? Only by reading > documentation? Yes. Either way, the timestamp should follow some format defined in documentation. > 2. You wish to say it will be future time of 20:00 o'clock, but time > zone definition can change, so if it can change, why use time zone > definition? To get notified about the change. > 3. UTC offset is displayed for past, as such time is accurate, but if > you display it for future, be aware that it is wrong for reason > that you cannot know the UTC offset in future without time > zone. Just display UTC time. Offset is not relevant, it will be > displayed to every user in their local time anyway, once they get > UTC. It may or may not be displayed. Because Org should be readable as plain text. > 4. Hypothetical example of clear timestamp for future: > [2024-02-04 12:00! @-08,America/Vancouver] > where the time would be stamped with "!" and that would mean that in the time zone, meeting is at 12 o'clock. > It would assume that UTC offset can change in future, but 12:00 clock would be authoritative time for future. This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver? >> > Maybe this way (hypothetically): >> > >> > [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED] >> > >> > as that way you would give signal to program that you want UTC fixed >> > time in future, and not 12:00 o'clock necessary. >> >> I am sorry, but I don't understand what you mean by UTC-FIXED. > > You mentioned it, you wish to have offset and to remain UTC fixed. > > And UTC is not fixed, it is either UTC without offset, or time zone > with UTC offset. > > But if you do wish, you have to make "tag" somehow, for computer > program to know what you mean, "UTC-FIXED" is only hypothetical tag. Sorry but I still don't understand. For me, -08 is GMT+08 nautical time zone. Short form. America/Vancouver is a time zone. What is America/Vancouver/UTC-FIXED? >> It is sometimes easier to define UTC time +offset instead of doing an >> extra conversion in your head. > > I hope you understood the difference. > > Providing UTC time plus some offset is inconclusive. It is idea that > is not aligned with what international community is doing. > > Provide UTC time. > > Or provide time zone plus UTC offset. > > Your idea as such is alright, but is individual, and it has to be > coordinated with what other programs are doing. Otherwise it become > confusing. > > Remember the reference on iCalendar, "not do do that". > > iCalendar provides either UTC time, or date, time and time zone. iCalendar is not the only source of truth. The suggested offsets are what ISO8601 defines. iCalendar explicitly disregards the fixed offsets for some iCalendar-specific reasons. It is iCalendar that is not being aligned with more common standard. >> > Then it becomes clear that it will be the UTC offset in future with >> > assumed mentiond time zone. >> > >> > But if you mix UTC offset, plus the time zone for future, that makes >> > little sense, unless you introduce some tags that timestamp is >> > recognizable as using UTC time, or that it uses date/time and time >> >> The problem being addressed with @+08,!Asia/Singapore is possible future >> change in time zone. > > That problem is solved, if you use TZ database: > > - in case of change of time zone, the TZ database will provide future > adjustment, there may be new name of new time zone. > > - in case of change of UTC offset, the TZ database in future will know > it. Your statement is true only when TZ database is guaranteed to be up-to-date. It is not always the case. Consider opening an Org document on machine with out-of-date TZ database. > I will never miss the meeting provided program consults TZ database. You will not. But I can see myself missing the meeting and assuming the time "as usual". > But if I have 2 timestamps, that is different situation. > > You need no UTC offset for future time representation. > > Also good to read: > https://engineering.q42.nl/why-always-use-utc-is-bad-advice/ > > Also good to read: > https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/ The second link illustrates exactly UTC offset + also time zone name. Similar to what I proposed. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at