From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id OKnDClCJ2mPcswAAbAwnHQ (envelope-from ) for ; Wed, 01 Feb 2023 16:46:24 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id EFvlCVCJ2mP+dwAAG6o9tA (envelope-from ) for ; Wed, 01 Feb 2023 16:46:24 +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 D1B501F388 for ; Wed, 1 Feb 2023 16:46:23 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNFIb-00037a-Og; Wed, 01 Feb 2023 10:45:25 -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 1pNFIR-00035x-Pz for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 10:45:15 -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 1pNFIQ-0001rD-3l for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 10:45:15 -0500 Received: from localhost ([::ffff:197.239.7.190]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103957.0000000063DA890B.0000516C; Wed, 01 Feb 2023 08:45:15 -0700 Date: Wed, 1 Feb 2023 17:53:13 +0300 From: Jean Louis To: Ihor Radchenko Cc: Tim Cross , tomas@tuxteam.de, emacs-orgmode@gnu.org Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) Message-ID: Mail-Followup-To: Ihor Radchenko , Tim Cross , tomas@tuxteam.de, emacs-orgmode@gnu.org References: <2150768.1675077958@archlinux> <87tu063ox2.fsf@localhost> <87h6w63jgg.fsf@localhost> <86wn51g661.fsf@gmail.com> <87357pn57t.fsf@localhost> <86sffpg1bv.fsf@gmail.com> <87wn51lmia.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87wn51lmia.fsf@localhost> 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: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no 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-Seal: i=1; s=key1; d=yhetil.org; t=1675266383; a=rsa-sha256; cv=none; b=Vn6LwSvx+YLOzqA+5rzQAOikBfiBK97tAra/6OuPzos3xym1iAGgx92nJgwcY7zabYmIed 4YqC5cpRrbYqYXilkpyurxhjC/SMtAVUGZ/W6cNNK1HwZd8RMcjczcbQ73Bevqnegg95Kp KP9fh63hF5Z4eEvXdZTTz2WBz/aAUbhTpWblIbnLet7oRaVzDtFRnMnX6205rW+5PO//av HqkuqI+kD3ga8xOBfWEUCeT9lj7GynMMJZHxWXUjm/hG10Gj3S/MW+KAJllJMuHUqr4f6f 5e5doB1xKEVrqdwP2PKKcgM72L8JBUeAJ1HHtZ4/DkVyVkRKdofRBmUntRoKlA== 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675266383; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=XTj3A+T4iTkKE+gLY/pmadu3RCzKOnolabmU2yBRN4g=; b=dpD7lQdM5qoaOx3kx3R4XkWW9dutQ9ImeycLy5ALUsQdPJVK0sg5ocUIYNRHrv2sbEuhNy gaYSznGW5MQiZgwUas0M8ArEdeG8exjxcBBlKYsGWMxRLs6bupTRXk9ld2ur8ZH2zN36AX J5egFeGwIAZijq+3+XVN4lNAUef6rrLjXABd0w+kebBNHHG0AjLbo8aB5H2BdapwkFhPzn HpOB2Tg8fXASF0hngHQJYVz5K1R5Ybgs3lU+s6mV84LABRrGW8UJpUn8ztg3XRc1rTv8Ld wLg/a3M+zhEwAaH2uJmaJcXkK0OJA5vefPaftSTkfBax99dHwLKuoRKZLJZwWg== 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-Migadu-Spam-Score: 2.42 X-Spam-Score: 2.42 X-Migadu-Queue-Id: D1B501F388 X-TUID: UL8o5/nY7057 * Ihor Radchenko [2023-02-01 13:30]: > Tim Cross writes: > > > The real question is, can the additional complexity associated with > > including both a time zone name and an offset be justified in order to > > handle the very small number of time stamps which will fall within the > > daylight savings transition hour for those locations which have daylight > > savings? Keep[ing in mind that the complexity is less to do with the > > time stamp format and more to do with using that information in any > > meaningful sense. This, combined with the reduced readability of such > > time stamps and increased possibility of user confusion leads me to > > question if allowing time stamps with both offset and time zone together > > in the one time stamp is worthwhile. > > As I originally stated in the proposal, the real usefulness of combined > offset+time zone is asking Org to double-check the consistency: That is right, though that is not the fundamental reason for using UTC offset and time zone. Every good application should check if the time stamp is valid or not. It should not allow user to specify invalid time stamps, and it should not calculate and generate invalid time stamps. The reason for UTC offset is future possible political changes of the UTC offset. It shall be assumed that time stamp from past was correct, that it was generated by application that was using the time zone database, but the UTC offset in present time could be changed, just as it was mentioned for the Russian decision recently. By using UTC offset and time zone from past, one can then use present UTC offset definitions and calculate differences. However, there are still rare changes with the past time zone definitions. Using UTC offset for future time stamps is IMHO possibly much more problematic for the same reason of possible changes in future. > Consider a time stamp far in future [2052-11-12 12:00+08 @!Asia/Singapore] > The time zone rules for Asia/Singapore may or may not remain the same > due to political uncertainty. Today, we expect the offset to remain +08. > If it changes in future, Org will warn the user. Very right. > In addition, I find specifying both the time zone and the offset > useful for readability: Thank you. > Complex time zones in timestamps will not rely on user's computer having > the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London] > unambiguously specifies the UTC offset yet emphasizing that the > timestamp is related to specific location (Europe/London, but not > Europe/Paris). In fact, one may somewhat abuse this format and specify > [1916-09-12 12:00+01 @France/Marseille] emphasizing the location. Then if they are not to relay on time zone database, on what they can rely as alternative? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/