From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 SK+/Fi2J2mP9JAEAbAwnHQ (envelope-from ) for ; Wed, 01 Feb 2023 16:45:49 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id EEfEFi2J2mMdCAAA9RJhRA (envelope-from ) for ; Wed, 01 Feb 2023 16:45:49 +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 0151D1F2C6 for ; Wed, 1 Feb 2023 16:45:48 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNFIJ-000341-AY; Wed, 01 Feb 2023 10:45:07 -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 1pNFIH-00033j-Qv for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 10:45:05 -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 1pNFIF-0001rD-6u for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 10:45:05 -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.0000000063DA8900.00005156; Wed, 01 Feb 2023 08:45:04 -0700 Date: Wed, 1 Feb 2023 17:43:26 +0300 From: Jean Louis To: Tim Cross Cc: Ihor Radchenko , 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: Tim Cross , Ihor Radchenko , tomas@tuxteam.de, emacs-orgmode@gnu.org References: <87lelo8c9r.fsf@localhost> <2150768.1675077958@archlinux> <87tu063ox2.fsf@localhost> <87h6w63jgg.fsf@localhost> <86wn51g661.fsf@gmail.com> <87357pn57t.fsf@localhost> <86sffpg1bv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <86sffpg1bv.fsf@gmail.com> 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675266349; 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=+35xv9VcHBE34FCyk1D27oGmGiq1FP34mBR53bWhnFQ=; b=T1feOOo/LhpBVxH8ZvCYJ99XwRSspz1vcOn2NsNiqvCWj24fj317Pj1u1FCPBNuI36rkUD NRFeLHRY8vlEm60RyC6SBj7tVd80HCCgqYNt6ODqCOeLZHe7rKrLiuQ0NjJgddOAxTE9kP NkaDfqscFz+Y5Sks0dCOCaAeX0pIFK4k1PfuQ7odudppLSv6JMtVfYp9WvqW11gu2z5r70 hFQEAZDCCaZSdu3petC7Jwt0lczEa9FZblnBuJwrR9N6Qzae0N8A4LgCpMTLjT0dIqAECS EYITKL40jgputcf4LH5Pp02wq5M3I5IO4D3GNR/3LkPj6pmWOsb6QSYecqLcbg== 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=1675266349; a=rsa-sha256; cv=none; b=nUwNMBwzRepAMzrIQ3PfUShJ9QF5GffxIrl0ajoNcbM03VsRjeYVTYz14g0WfA3KwoOd16 trp9wnpnJpFcB+S8OSIKxNlocpcKNSm69m4ubSi6274Ccx65ewKEd1Bma0ArquPcmCjqHy tITscFHiJx31YiPL/O0fGPgF7YvO78EqzTRqkPyHuqe6nTjTlkCwWgUNRTTEG2ccKYU+68 MdTTrT9c66jOL93T4Kz6usbEvC4mITD7Ei8IVi2oNZOUYgigfowQcykp83F+C3kDEcp2mz IY7mROyGBhfKMwAj6HEgAP7m6HeB1Yz2tPu5PkYJthnpk8XW1B1HJCo9E7otkw== 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: scn0.migadu.com X-Spam-Score: -1.68 X-Migadu-Queue-Id: 0151D1F2C6 X-Migadu-Spam-Score: -1.68 X-TUID: iP+hmIOfvRvx * Tim Cross [2023-02-01 12:53]: > > Let me try to explain better. Just specifying time zone is ambiguous > > once per year during daylight transition. > > > > [2023-03-29 02:30 @Europe/Berlin] is special. > > > > According to https://www.timeanddate.com/time/zone/germany/berlin, > > 2023-03-29 is the time when the clock is shifted one hour back due to > > the daylight saving transition. The wall time goes like > > > > 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> 2:30 (again!) > > > > So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: before > > and after the transition. Specifying explicit offset is thus necessary > > in this specific scenario to disambiguate the timestamp: > > > > [2023-03-29 02:30+2 @Europe/Berlin] (before transition) > > [2023-03-29 02:30+1 @Europe/Berlin] (after transition) > > OK, in that case, I think what we are in danger of here is letting > the perfect be the enemy of good. > > The problems of daylight savings transition points is fairly well > understood and I think it is fairly well accepted that there is > ambiguity arising from the use of daylight savings. The only ambiguity is if you miss to understand that "time zone" definition already contains specification of daylight savings. If you do understand it, then there will be no ambiguity at all. > 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? That additional complexity is important for future, as we cannot know what will be the future UTC offset due to political changes! > 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. That is very correct, that is why Org shall keep time stamps simple in it's basic form and allow users to specify precision as they wish. > 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 we promote Org to be good for "reproducible research" then for those people will be of value, and many other groups who need time precision. https://html.duckduckgo.com/html/?q=org+mode+reproducible -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/