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 eDFsNZPp6GO04AAAbAwnHQ (envelope-from ) for ; Sun, 12 Feb 2023 14:28:51 +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 YG4kNZPp6GMjSwEAauVa8A (envelope-from ) for ; Sun, 12 Feb 2023 14:28:51 +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 5681543F56 for ; Sun, 12 Feb 2023 14:28:51 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRCOe-0004nb-SR; Sun, 12 Feb 2023 08:28:00 -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 1pRCOc-0004nN-MP for emacs-orgmode@gnu.org; Sun, 12 Feb 2023 08:27:58 -0500 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pRCOZ-0004b2-8V for emacs-orgmode@gnu.org; Sun, 12 Feb 2023 08:27:58 -0500 Received: by mail-wr1-x431.google.com with SMTP id h16so9690846wrz.12 for ; Sun, 12 Feb 2023 05:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-language:subject:to:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=TqW5sDRjbygtBAWlpFflA9H/e6DXeMiElvlfxeqnCcs=; b=YUPjkt0W816HcPtyMd2ahUzOpGLeBRqp8N+5b+EZwWVDbTb6gNDiyfIAvwRjWW7wb2 Ld2eAkWvkiqnHosyc50kmcX86chm+mqbBYjgy2cOZ6JmVyU7qTMxFpRhZJHo1IazSKKP aaE6s1a7K+0aBdCDYZBvNp/6ebC8rCjQlGKTgLi9E5M8Itp9f2Gx1PykOfXgYtMt90gP 4ZLVWcPyvqCjMXUiZi8jmhO2btgQx126P1e89qKu54oReuylQ19xI/AH4vxfcyE4g08U 1/YTVQMwozKdOAR8C/JU4YobdrkSbpgHBv37wWOz0eBSshT62dtNHXlwz26/775QkJrq bgIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=from:content-language:subject:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TqW5sDRjbygtBAWlpFflA9H/e6DXeMiElvlfxeqnCcs=; b=jDWSUIGhk0uI831YaC9CVM1pyVubAsDm8tet2kX1+fuTtS0upPs83vJgNeGfOUM8X4 C/bmTDLpvNg9+UUapKvmq3PfOQqjjmgl3iEcs9VMYBEppCw1kzJNcS4did2iexCqxznS 4y4ohkHCzQcxdX5OWTpN5mHsfnP3DQEYPTo0nBdTGVmDqWPjC4eDFpPw0/8gWRZha13K TFiql/Ufyz/znL1rfLuHwKUUIQ1QoOU+zwjB0p1AvRkBNcaDzDFSK/rhw6ErXTF6bMju mabnw/DmAHIkUCcxHB6qOEXWRRGxDFIcC0trX9N+uyNN2QNbACTnEoMkNIDVlRV4BqwV 3k2A== X-Gm-Message-State: AO0yUKUXS3xFDW99V7yQ7VVqTNf6xkCoZqOiBOwZZSYN436nnY21sQ/Q kqLgCm9g8kISBEHzn25uQhi6IIZtn9Y= X-Google-Smtp-Source: AK7set+IggLryVk53krxha3P8b1aDPu/dQjUzwyw9swGqxn4KMqHf15o8qApEDSnCgO/okOrK2niyQ== X-Received: by 2002:adf:dc92:0:b0:2bf:b741:3e0f with SMTP id r18-20020adfdc92000000b002bfb7413e0fmr18257285wrj.41.1676208472904; Sun, 12 Feb 2023 05:27:52 -0800 (PST) Received: from [192.168.0.97] (static-222-20-25-46.ipcom.comunitel.net. [46.25.20.222]) by smtp.gmail.com with ESMTPSA id k16-20020adfe8d0000000b002c54536c662sm6880014wrn.34.2023.02.12.05.27.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Feb 2023 05:27:52 -0800 (PST) Content-Type: multipart/alternative; boundary="------------NMK7zZoGmIMtGR8MLOy0OTJj" Message-ID: Date: Sun, 12 Feb 2023 14:27:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 To: 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) Content-Language: en-GB From: Ypo Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=ypuntot@gmail.com; helo=mail-wr1-x431.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, 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YUPjkt0W; 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=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1676208531; a=rsa-sha256; cv=none; b=Cl056XnVc7CVynElt4Axa6nOpHjhfWezFZlWJDcmix32eUmsVK4gK3KWXfox9qAXhcfc14 4LQbxGysbo1eui3genmmNNbi9BsZOOwppqFNJcsX3BO67smHsXq9qk3cl5OcO8Xv4Dqoqn ngA5T1B3QLpj896Wh/c4ksI9EgNVH0DSII0+qGSJiJedYPmF5Y6TgPLZtRX8UnNhjOlS4L QLib+eGqaYsU8hvdMCCRntmBv6saahnpKC59g1jC+S87/DTrQvNTHsoazOnCdmhSXGE++C PLAzyd1+dbsVGpDZ0U8JSWEzOL3fGvPsbTk4PCtqkXYgQvHopNLvj3WypyL5Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1676208531; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=TqW5sDRjbygtBAWlpFflA9H/e6DXeMiElvlfxeqnCcs=; b=QnnqBOkTQIdj3oWKTFf14iRYjwd7SzniwZ1giBEYzxlknM5gIo3TLVBa34ZtRARMI/112F y5ERBSOnkk+EcuiglaGuTSlEzb+oZ732MQ3vq1Aa+/csGM0Ho7+I1ZCARtHu9hvX09h/5M zx2DkJsKuhAoL86NwFI6Vrl4+Y+D/egiyNq5TPYo07spLFKFK/P7+JNUpO+eRCVB1B63DO wkIKCoddSHF2gWazBmo9CXDQSutbBS/a2kydSQVD3eHEHF9jArW6Y+d0BWUhMXibuwCS4x E+GbN8kRTM8CH5BrAaZ+9GchdGkdqKxnh3EM6kxu+Dwk+39iiQQvZz/HQNaISg== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -5.32 X-Spam-Score: -5.32 X-Migadu-Queue-Id: 5681543F56 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YUPjkt0W; 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=gmail.com X-TUID: zfB8dKkeo41W This is a multi-part message in MIME format. --------------NMK7zZoGmIMtGR8MLOy0OTJj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Could it be reasonable to collect the hypothetical cases where relative timestamps would be used? So, alternatives and solutions could be evaluated more easily. For example: | External Input                                          | User's input                     | Org output                             | Agenda output (local time) | Org time storing     | |---------------------------------------------------------+----------------------------------+----------------------------------------+----------------------------+----------------------| | Meeting at 09:37:54, 28 February 2023, in Foz do Iguaçu | [2023-02-28 ma. 09:37 @UTC-3]    | [2023-02-28 ma. 09:37 @UTC-3]          | [2023-02-28 ma. 13:37]     | 20230228T12:37:54,68 | | Same case as above                                      | [2023-02-28 ma. 09:37 @timezone] | [2023-02-28 ma. 09:37 @UTC-3,timezone] | [2023-02-28 ma. 13:37]     | 20230228T12:37:54,68 | | Party at my home, tomorrow                              | [2023-02-13 lu. 14:15]           | [2023-02-13 lu. 14:15 @UTC+1,timezone] | [2023-02-13 lu. 14:15]     | 20230213T13:15:54,68 | - I didn't expect this: it is more difficult for me to find the timezone, and to write it in the correct format, than to find the UTC offset. - Maybe org output should always show the time zone, since for calculations - Should convert show every timestamp timezone, so we know local timezone is correct? - Sorry for the table format, I don't know how to export it from orgmode to thunderbird's mail editor. > ------------------------------------------------------------------------ > * Max Nikulin [2023-02-11 07:47]: > >/On 10/02/2023 10:29, Jean Louis wrote:/ > >/> 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed/ > >/> UTC"/ > >// > >/I do not see any reason why obviously invalid timestamp draws so much/ > >/attention./ > >// > >/Resolution may be rather concise: behavior is *undefined* since field > values/ > >/are mutually inconsistent. Perhaps implementation may prefer to treat > it as/ > >/2030-02-09T12:00:00-0800 discarding UTC as time zone specifier. > `org-lint'/ > >/should issue a warning requesting a user action./ > > Thank you! > > I have demonstrated that Etar application from F-Droid would disregard > what is invalid and basically only enter valid time. Same for Google > calendar, it would disregard invalid timestamp (even though not > represented as above), and it would enter only valid one. PostgreSQL > will "silently" ignore what does not belong to it. > > One can search for "silent" here: > https://www.postgresql.org/docs/current/datatype-datetime.html > > >/Could you explain what is wrong with the following (without timezone)?/ > >// > >/2030-02-09 12:00 -0800/ > >// > >/I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z > that is a/ > >/UTC timestamp./ > > That is not same case as Ihor, when he designated it as > > 2030-02-09 12:00 -0800 @UTC > because there are no offsets @UTC time zone. > > In this different case you wish to say that it is: > > time of 2030-02-09 12:00 -0800 whereby -0800 is UTC offset from floating time > 2030-02-09 12:00, and one can derive UTC time. > > That is totally alright as representation of time. That is how past > timestamps are represented in local time. > > Why not -- you can use it for future. > > I find it less useful for exchange purposes, almost useless, but you > can do. Because if you store time as UTC, you can always see local > time anywhere in the world. But if programmers wish to do that to Org, > okay fine. > > It is different time type representation, that does not exist in ISO > 8601, but why not, you can include it in Org. > > You just be sure that you put a "tag" or such representation that > users will know what is it, even from plain text. > > >/The format with explicit offset may be convenient for a person/ > >/living in an area that *likely* will have -08:00 offset and who/ > >/would like to watch some astronomical event such as lunar eclipse/ > >/and who had a plan to connect to some telescope on the opposite side/ > >/of the globe. Event time will not change if local time changed. Both/ > >/variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be/ > >/presented as "2030-02-09 12:00" to users./ > > And now you speak of presentation. But then why store it with > 2030-02-09T12:00:00-0800 when you can store it as 2030-02-09T20:00:00Z > and have representation be same "2030-02-09 12:00" to users. > > So that is only addition to programmer. > > Remember that not even databases store the time like that. It is > either UTC time, or date, time, and some time zone stored separately. > > >/If timezone offset is changed both variants will converted to/ > >/"13:00" or "11:00" depending on sign of change./ > > Correct. I understand you want to say that representation of time for > that UTC time zone will be modified depnding of change, and that is > correct. > > >/So the format with offset is human friendly because it gives a hint/ > >/concerning *probable* value of local time still remaining *precise*/ > >/in respect to UTC./ > > This representation of time is human friendly: > 2030-02-09 12:00 -0800 and that is the way how I daily see my > timestamps, like this: 2023-02-12 12:59:52.839773+03 > which does not differ much from that one. > > However, my timestamp is only represented with +03 UTC offset. It is > not stored with UTC offset. > > Storing values is not equal to representing values. > > - In other software values are not stored as "UTC time that has > offset" > > - It is stored as "UTC time" > > - Offset is calculated from time zone and represented to user. > > Of course you need not follow what other software does. > > Though I think you need rather exact designation for users to > unmistakably can understand what you mean with it: > > - Right now when I press C-c . I get: <2023-02-12 Sun> > > - C-u C-c . and I get <2023-02-12 Sun 13:03> > > - Then I can think you (developers) will invent something like: > <2023-02-12 Sun 13:03 @Europe/Berlin> (whereby one has to avoid > invalid time stamps), which is UTC time: 2023-02-12 12:03:00 > > - Then I can think you would invent time stamp which you proposed, > something like: <2023-02-12 12:00 -08:00> which in this case cannot > have day representation, as one cannot know which day is that, > right? > > And in this case that timestamp would mean it is 20:00 o'clock UTC > time. > > And which can be replaced with <2023-02-12 20:00 @UTC> > > I am just not sure if that will be enough human friendly to say: > <2023-02-12 12:00 -08:00> to people, as there is no designation that > it is UTC time, and one cannot use "@UTC" as that would be wrong. > > Maybe designation is not necessary? > > When we consider how good calendars work, they will always ask user > for the time zone. There is settings. > > And then if you write that event is on Sunday 20 o'clock, it will be > considered 20 o'clock at that time zone. > > When you send it, it will be maybe converted to UTC time, but maybe > not, maybe with time zone designation. > > In any case remote user will either get UTC time or date, time with > time zone. > > Getting time representation with offset, to calculate UTC time seem > redundant. > > But why not, it is possible. > > Will you do it, practically implement it? > > >/I find the following as acceptable, but confusing to some degree:/ > >// > >/2030-02-09 12:00 -08/ > >// > >/just because "-08" is currently used in TZ database as time zone/ > >/abbreviation (a string similar to "BST"), not as offset that is > represented/ > >/in wide spread formats as -0800 or -08:00. Unfortunately the latter > causes/ > >/ambiguity in the context of Org./ > > That is why is better not to use TZ time zone abbreviation for future times! > > For past times, is somehow okay. For future no. > > Let me consult the database. > > #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline > :database rcdbusiness :dbuser maddox > SELECT name, abbrev, utc_offset, is_dst > FROM pg_timezone_names where abbrev = '-08'; > #+END_SRC > > #+RESULTS: > | name | abbrev | utc_offset | is_dst | > |------------------------+--------+------------+--------| > | Etc/GMT+8 | -08 | -08:00:00 | f | > | Pacific/Pitcairn | -08 | -08:00:00 | f | > | posix/Etc/GMT+8 | -08 | -08:00:00 | f | > | posix/Pacific/Pitcairn | -08 | -08:00:00 | f | > > In your example, you should not use time zone abbreviations to say > that it is UTC time with offset. > > Better use accurate offset (which is not UTC offset, as that is changeable). > > This is better if you really wish to designate the time with offset > which represents UTC time: > > 2030-02-09 12:00 -08:00 > > Because you are rounding for no good reason! You have introduced new > type of time storage, which is time with offset representing UTC time. > > While UTC offsets are mostly rounded, you are introducing not the UTC > offset, but "offset". > > That means that following is also just fine: > > 2030-02-09 11:47 -08:12 > > Which is not common. But you insist on using time with offset, that > represents UTC time, however, then you should not be using "UTC > offsets" for such representations, but leave to users what "offset" to > add or deduce, for UTC calculation. > > I am against such storage, and representation, but either: > > - as UTC time, without offset > > - or as date, time, time zone, as UTC offset can be calculated in future time > points > > But we can see that Org is different case, it is textual, not database. > > However, this time: <2023-02-12 13:29> was always considered floating, > and then by changing anything it can become [2023-02-13 Mon 13:29], > the day is "added" automatically. > > So one needs some "tag" for time represented as UTC time but with > offset, like [2023-02-13 13:29 @TO-UTC -08:00] > > it cannot be "@UTC" as that is time zone. You have to invent how to > represent it, that is unmistakable to other representations. > > -- > Jean > > Take action in Free Software Foundation campaigns: > https://www.fsf.org/campaigns > > In support of Richard M. Stallman > https://stallmansupport.org/ > > > *From*: Jean Louis > *Subject*: Re: [POLL] Proposed syntax for timestamps with time zone > info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps > and org-agenda) > *Date*: Sun, 12 Feb 2023 13:32:21 +0300 > *User-agent*: Mutt/2.2.9+54 (af2080d) (2022-11-21) > --------------NMK7zZoGmIMtGR8MLOy0OTJj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Could it be reasonable to collect the hypothetical cases where relative timestamps would be used?  
So, alternatives and solutions could be evaluated more easily.  
For example:  


| External Input                                          | User's input                     | Org output                             | Agenda output (local time) | Org time storing     |

|---------------------------------------------------------+----------------------------------+----------------------------------------+----------------------------+----------------------|
| Meeting at 09:37:54, 28 February 2023, in Foz do Iguaçu | [2023-02-28 ma. 09:37 @UTC-3]    | [2023-02-28 ma. 09:37 @UTC-3]          | [2023-02-28 ma. 13:37]     | 20230228T12:37:54,68 |
| Same case as above                                      | [2023-02-28 ma. 09:37 @timezone] | [2023-02-28 ma. 09:37 @UTC-3,timezone] | [2023-02-28 ma. 13:37]     | 20230228T12:37:54,68 |
| Party at my home, tomorrow                              | [2023-02-13 lu. 14:15]           | [2023-02-13 lu. 14:15 @UTC+1,timezone] | [2023-02-13 lu. 14:15]     | 20230213T13:15:54,68 |


- I didn't expect this: it is more difficult for me to find the timezone, and to write it in the correct format, than to find the UTC offset.  
 
- Maybe org output should always show the time zone, since for calculations  
 

- Should convert show every timestamp timezone, so we know local timezone is correct?

- Sorry for the table format, I don't know how to export it from orgmode to thunderbird's mail editor.




* Max Nikulin <manikulin@gmail.com> [2023-02-11 07:47]:
> On 10/02/2023 10:29, Jean Louis wrote:
> > 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed
> > UTC"
> 
> I do not see any reason why obviously invalid timestamp draws so much
> attention.
> 
> Resolution may be rather concise: behavior is *undefined* since field values
> are mutually inconsistent. Perhaps implementation may prefer to treat it as
> 2030-02-09T12:00:00-0800 discarding UTC as time zone specifier. `org-lint'
> should issue a warning requesting a user action.

Thank you!

I have demonstrated that Etar application from F-Droid would disregard
what is invalid and basically only enter valid time. Same for Google
calendar, it would disregard invalid timestamp (even though not
represented as above), and it would enter only valid one. PostgreSQL
will "silently" ignore what does not belong to it.

One can search for "silent" here:
https://www.postgresql.org/docs/current/datatype-datetime.html

> Could you explain what is wrong with the following (without timezone)?
> 
> 2030-02-09 12:00 -0800
> 
> I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z that is a
> UTC timestamp.

That is not same case as Ihor, when he designated it as 

2030-02-09 12:00 -0800 @UTC
because there are no offsets @UTC time zone.

In this different case you wish to say that it is:

time of 2030-02-09 12:00 -0800 whereby -0800 is UTC offset from floating time
2030-02-09 12:00, and one can derive UTC time.

That is totally alright as representation of time. That is how past
timestamps are represented in local time.

Why not -- you can use it for future.

I find it less useful for exchange purposes, almost useless, but you
can do. Because if you store time as UTC, you can always see local
time anywhere in the world. But if programmers wish to do that to Org,
okay fine.

It is different time type representation, that does not exist in ISO
8601, but why not, you can include it in Org.

You just be sure that you put a "tag" or such representation that
users will know what is it, even from plain text.

> The format with explicit offset may be convenient for a person
> living in an area that *likely* will have -08:00 offset and who
> would like to watch some astronomical event such as lunar eclipse
> and who had a plan to connect to some telescope on the opposite side
> of the globe. Event time will not change if local time changed. Both
> variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be
> presented as "2030-02-09 12:00" to users.

And now you speak of presentation. But then why store it with
2030-02-09T12:00:00-0800 when you can store it as 2030-02-09T20:00:00Z
and have representation be same "2030-02-09 12:00" to users.

So that is only addition to programmer.

Remember that not even databases store the time like that. It is
either UTC time, or date, time, and some time zone stored separately.

> If timezone offset is changed both variants will converted to
> "13:00" or "11:00" depending on sign of change.

Correct. I understand you want to say that representation of time for
that UTC time zone will be modified depnding of change, and that is
correct.

> So the format with offset is human friendly because it gives a hint
> concerning *probable* value of local time still remaining *precise*
> in respect to UTC.

This representation of time is human friendly:
2030-02-09 12:00 -0800 and that is the way how I daily see my
timestamps, like this: 2023-02-12 12:59:52.839773+03
which does not differ much from that one.

However, my timestamp is only represented with +03 UTC offset. It is
not stored with UTC offset.

Storing values is not equal to representing values.

- In other software values are not stored as "UTC time that has
  offset"

- It is stored as "UTC time"

- Offset is calculated from time zone and represented to user.

Of course you need not follow what other software does.

Though I think you need rather exact designation for users to
unmistakably can understand what you mean with it:

- Right now when I press C-c . I get: <2023-02-12 Sun>

- C-u C-c . and I get <2023-02-12 Sun 13:03>

- Then I can think you (developers) will invent something like:
  <2023-02-12 Sun 13:03 @Europe/Berlin> (whereby one has to avoid
  invalid time stamps), which is UTC time: 2023-02-12 12:03:00

- Then I can think you would invent time stamp which you proposed,
  something like: <2023-02-12 12:00 -08:00> which in this case cannot
  have day representation, as one cannot know which day is that,
  right?

  And in this case that timestamp would mean it is 20:00 o'clock UTC
  time.

  And which can be replaced with <2023-02-12 20:00 @UTC>

  I am just not sure if that will be enough human friendly to say:
  <2023-02-12 12:00 -08:00> to people, as there is no designation that
  it is UTC time, and one cannot use "@UTC" as that would be wrong.

  Maybe designation is not necessary?
  
When we consider how good calendars work, they will always ask user
for the time zone. There is settings.

And then if you write that event is on Sunday 20 o'clock, it will be
considered 20 o'clock at that time zone.

When you send it, it will be maybe converted to UTC time, but maybe
not, maybe with time zone designation.

In any case remote user will either get UTC time or date, time with
time zone.

Getting time representation with offset, to calculate UTC time seem
redundant.

But why not, it is possible.

Will you do it, practically implement it?

> I find the following as acceptable, but confusing to some degree:
> 
> 2030-02-09 12:00 -08
> 
> just because "-08" is currently used in TZ database as time zone
> abbreviation (a string similar to "BST"), not as offset that is represented
> in wide spread formats as -0800 or -08:00. Unfortunately the latter causes
> ambiguity in the context of Org.

That is why is better not to use TZ time zone abbreviation for future times!

For past times, is somehow okay. For future no.

Let me consult the database.

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline 
:database rcdbusiness :dbuser maddox
SELECT name, abbrev,  utc_offset, is_dst
FROM pg_timezone_names where abbrev = '-08';
#+END_SRC

#+RESULTS:
| name                   | abbrev | utc_offset | is_dst |
|------------------------+--------+------------+--------|
| Etc/GMT+8              |    -08 |  -08:00:00 | f      |
| Pacific/Pitcairn       |    -08 |  -08:00:00 | f      |
| posix/Etc/GMT+8        |    -08 |  -08:00:00 | f      |
| posix/Pacific/Pitcairn |    -08 |  -08:00:00 | f      |

In your example, you should not use time zone abbreviations to say
that it is UTC time with offset.

Better use accurate offset (which is not UTC offset, as that is changeable).

This is better if you really wish to designate the time with offset
which represents UTC time:

2030-02-09 12:00 -08:00

Because you are rounding for no good reason! You have introduced new
type of time storage, which is time with offset representing UTC time. 

While UTC offsets are mostly rounded, you are introducing not the UTC
offset, but "offset".

That means that following is also just fine:

2030-02-09 11:47 -08:12

Which is not common. But you insist on using time with offset, that
represents UTC time, however, then you should not be using "UTC
offsets" for such representations, but leave to users what "offset" to
add or deduce, for UTC calculation.

I am against such storage, and representation, but either:

- as UTC time, without offset

- or as date, time, time zone, as UTC offset can be calculated in future time 
points

But we can see that Org is different case, it is textual, not database. 

However, this time: <2023-02-12 13:29> was always considered floating,
and then by changing anything it can become [2023-02-13 Mon 13:29],
the day is "added" automatically.

So one needs some "tag" for time represented as UTC time but with
offset, like [2023-02-13 13:29 @TO-UTC -08:00]

it cannot be "@UTC" as that is time zone. You have to invent how to
represent it, that is unmistakable to other representations.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/
From: Jean Louis
Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
Date: Sun, 12 Feb 2023 13:32:21 +0300
User-agent: Mutt/2.2.9+54 (af2080d) (2022-11-21)

--------------NMK7zZoGmIMtGR8MLOy0OTJj--