From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 2M8rO+vz3WOESQAAbAwnHQ (envelope-from ) for ; Sat, 04 Feb 2023 06:58:04 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id mOU9Ouvz3WNISgEAG6o9tA (envelope-from ) for ; Sat, 04 Feb 2023 06:58:03 +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 6B243FD41 for ; Sat, 4 Feb 2023 06:58:03 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pOBXy-0000Q5-Uy; Sat, 04 Feb 2023 00:57:11 -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 1pOBXx-0000Ps-RQ for emacs-orgmode@gnu.org; Sat, 04 Feb 2023 00:57:10 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOBXv-0007nZ-V8 for emacs-orgmode@gnu.org; Sat, 04 Feb 2023 00:57:09 -0500 Received: from localhost ([::ffff:197.239.13.92]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103A90.0000000063DDF396.00005B33; Fri, 03 Feb 2023 22:56:38 -0700 Date: Sat, 4 Feb 2023 08:07:03 +0300 From: Jean Louis To: emacs-orgmode@gnu.org Subject: Re: [POLL] Proposed syntax for timestamps with time zone info Message-ID: Mail-Followup-To: emacs-orgmode@gnu.org References: <2150768.1675077958@archlinux> <87tu063ox2.fsf@localhost> <87h6w63jgg.fsf@localhost> <86wn51g661.fsf@gmail.com> <87357pn57t.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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=1675490283; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=WDtQLhaF6+7aa6gWgc+qjACyb74cZzoSi+uXqJK/QPg=; b=FsMKXq6jCSVTvroQfCwluoYNEt7pYVlY1uxxF0NSysxFbdWf5N6w5LTI9NuhGq/LLv1V9Z lTeFJoB+/8+haLuVOnTf7CmaEb1bx8V2atLA9fUdXKLQvx2HGhn1t9iV/EIG7YHwtHYKab ueLwzGqR99tNXS7dk/4BBbqU+rFf8skQp3BCz+2q4/PUua3aJ/CvU5yxPCVLelgp2jblEl yUuoTdmnh1ChCrplWoE+iE9CSk/JmBT6SbgrrzL9VEVrt5WewX5bl780ly9aynTY7WKJRz fzEEQLVaEVC6PY9hv+YBDUKc4jBeBMqkP6tb+uIgby7gpNYlwiE6L3FX/CyCtQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1675490283; a=rsa-sha256; cv=none; b=HuryettTBPyKss9s961+xmGfDGWn9qOQJqvVkT6Q6BzJ6yEGiw7Bd4Wpt//PXyh6ErxCSj wAMyQMOzv8wPhFbO+NMjbrF5cm0ugLDIJoBNqMcaqA4TFhUEyf/V3/WjqL4P8VwyxkeVzQ BuPc499Z5Z4l8FR2PN0IO7sMwaOvZi+9u46KYb//pEiPToMfiTaqBHKkKslSbCFhr31uN2 K6TeF8kn+AECRfvIM+SYMsRt569fH4zgcgngm9jivdKGLyaf3YTbiQEjahNHJRbflJjw/t QlvAn2s2v4DvwXGHN1w83SD9Amxrm18gHvpKNou6vGYjDcxEPs7/NxQQK/A1lg== X-Migadu-Spam-Score: -2.38 X-Spam-Score: -2.38 X-Migadu-Queue-Id: 6B243FD41 Authentication-Results: aspmx1.migadu.com; dkim=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"; dmarc=none X-Migadu-Scanner: scn1.migadu.com X-TUID: W3aiAC1zoZhR * Stefan Nobis [2023-02-03 18:50]: > Jean Louis writes: > > > Specifying time zone is not ambiguous as long as you use the TZ > > database for specifications! > > That's wrong and you know it. What I know is based on research and good references. It seems you did not follow it. > For example > > [2023-10-29 02:30 @Europe/Berlin] > > is ambiguous. Period. You may put as many periods as you want. If you do not know how to generate timestamp that they are conclusive, then they will be always invalid or ambigous. Computer program that knows that your timestamp is most probably try to correct it, as saving time with invalid timestamp with some programs does not work, as I have demonstrated. Fact is that some timestamps mentioned in the conversations are invalid. Such invalid timestamps were generated by human, not by computer. Agree on what people internationally agreed. Do not generate it in first place. I can place any kind of text anywhere and I could say it is "timestamp", but that is valid for me, not for community that relies on international agreements. If user wish to do timestamp generation by hand, or some looney program wish to generate invalid timestamps, I can only say "good luck", but it is good to warn users and file bug reports for such program. Timestamp of course may be generated by human, and it can be ambigous. But why would you do that? Isn't it better to learn how to write non-ambigous timestamps? Or even better, to use good program to generate non-amgibious timestamp? Every user and programmer should strive to make computer, in this case Org program, to generate and calculate useful timestamps and how to increase that usefulness for users by being accurate. Programmer should not strive to generate invalid timestamps, and then prolong discussions how timestamp is invalid. That is programmer's problem. We have that problem in Org, solutions are in sight. It is not international problem at all as it is solved by ISO representation. All computer programs should use the internationally accepted time zone database and not those invalid timestamp representation but valid timestamp representation. And user should file bugs when they see that timestamps are either incorrectly represented, invalid, or there are some problems. It is easy to observe how will PostgreSQL understand those times with time zone being Europe/Berlin: Here it will tell that time of 01:30 has UTC offset of +02: select '2023-10-29 01:30:00'::timestamp at time zone 'Europe/Berlin'; timezone ------------------------ 2023-10-29 01:30:00+02 (1 row) Here it will tell that time of 02:30 has UTC offset of +01: select '2023-10-29 02:30:00'::timestamp at time zone 'Europe/Berlin'; timezone ------------------------ 2023-10-29 02:30:00+01 (1 row) Here it will tell that time of 02:30 has UTC offset of +01: select '2023-10-29 03:30:00'::timestamp at time zone 'Europe/Berlin'; timezone ------------------------ 2023-10-29 03:30:00+01 (1 row) Observe how the timesamp representation changes from '2023-10-29 01:59:59+02' to '2023-10-29 02:00:00+01' and how UTC offset is there to make it very clear. select '2023-10-29 01:59:59'::timestamp at time zone 'Europe/Berlin'; timezone ------------------------ 2023-10-29 01:59:59+02 (1 row) select '2023-10-29 02:00:00'::timestamp at time zone 'Europe/Berlin'; timezone ------------------------ 2023-10-29 02:00:00+01 (1 row) Above is happening because PostgreSQL observes time zone definition and knows how to represent that timestamp correctly. A looney program will not observe time zone, it will generate invalid or ambigious timestamps. Conclusion: ----------- Do use looney programs. Use timezone database information and international standards to represent and exchange time related information. > It would also be nice to eventually recognize, that we are talking > about readable syntax for humans, that is sometimes generated, > sometimes manually typed. Most of you comments does not really > resonate with this crucial design goal. Teach that human how to represent time correctly. Teach computer program to help human to correct incorrectly hand written timestamps to something that is reasonable, like Etar calendar does that. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/