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 WFZeB/gk2mP6AwAAbAwnHQ (envelope-from ) for ; Wed, 01 Feb 2023 09:38:16 +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 +CloB/gk2mNeBQEAauVa8A (envelope-from ) for ; Wed, 01 Feb 2023 09:38:16 +0100 Received: from lists.gnu.org (unknown [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 65B3036469 for ; Wed, 1 Feb 2023 09:38:13 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pN8bV-0005wN-OQ; Wed, 01 Feb 2023 03:36:29 -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 1pN8bU-0005sB-40 for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 03:36:28 -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 1pN8bS-0001k1-Cc for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 03:36:27 -0500 Received: from localhost ([::ffff:102.85.240.173]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000055D5E.0000000063DA2489.00002A7B; Wed, 01 Feb 2023 01:36:24 -0700 Date: Wed, 1 Feb 2023 11:32:16 +0300 From: Jean Louis To: Tim Cross Cc: 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 , tomas@tuxteam.de, emacs-orgmode@gnu.org References: <87pmb9k8oi.fsf@tsdye.online> <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> <87lelo8c9r.fsf@localhost> <2150768.1675077958@archlinux> <87tu063ox2.fsf@localhost> <87h6w63jgg.fsf@localhost> <86wn51g661.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86wn51g661.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: -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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675240693; 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=LNp/J1nqKblxbNoXm59QVz2YvsPajsKLNobp5Lf2I7o=; b=Xj9UxywJn7CqXQy3Bb8IRCj3jJsa8cbXpOQJt/Tm1fLuNS+utN4C5v9jfV1Vz59d2LvBB6 RSbr4iL07w3X5v2XKq+jrGiqRTBOKVcwCzBXXpBudjxQOlf6CaCIOT/r5iJrS0vrpYl2y8 aSw60wXz17IlaYehq8pBxEjQkpedFIhbMb60uro5F9ThgAo4jDdHao9Y5dVhyJODLvSIpt Xpq049ia2ZDDlEsRQLmcAc3d1KYmoZJyFmhZhgz9XmBcVbXWluOrLK5sK8MKH6D3mz4Vll 2AJUlcASKjn7CvsiTcyRnBqNaPfHdvZkLjrfnHHdl7n4gWdyTDuxNZKe3uK7Rw== 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=1675240693; a=rsa-sha256; cv=none; b=pRDrbInIj4tPaenfRiyTW/XUW9kQe9DZUBrVmNavvmZo4OffUwu2ollp0JioH8tVBQ0CCW bRfVpVQZdEb2VeHdAybVtdiZKQHEW4/pZ90kiWg3N9rvjpKvHcR61Z7ks/plQuAR5blywM y8HmvXnLC2V3X4yYpcQvCEv4GctwcT5LNTmDaxPgedwWwU/Dud/h0ceslKajIWv1z++x6r Wd2owIzR5HwkMRSjVsqS6aGYkJIB7D/A4b/232T3niV1b3B7pD5g4faEdHB7khlGIialG8 MWQ6L4AtfFktA2MrbjhMI5w+d9yg/iGU29r/+VuvLss5j6lQ6HLQkR2Kihv1fg== 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: 0.32 X-Migadu-Queue-Id: 65B3036469 X-Migadu-Spam-Score: 0.32 X-TUID: 7E0vghThSLTP * Tim Cross [2023-02-01 11:10]: > I think the confusion relates to context interpretation. If you see > @Europe/Berlin in isolation, then it is ambiguous as it can refer to > two different time zone definitions (standard v daylight savings). Of course, without the time stamp, the time zone alone cannot give time. > However, if you consider it in conjunction with a date and time, as > in 2023-03-23 02:30 @Europe/Berlin, then it isn't ambiguous - in > that case, it really just says 'Lookup the time zone offset in the > databse for Berlin as of that date and time. Exactly that. > Now that could change - for example, the German government might > make a temporary or permanent change that would change the offset > from UTC for that date+time the day after I look at it (or export > it). It cannot change in past. It will not change drastically or capriciously as Germany aligns with other countries and ISO standard. It is more likely that ISO non-members deviate from international coordination of time related definitions: ISO - Members: https://www.iso.org/members.html > Personally, I cannot see the use case of including both a fully > qualitifed time zone (as in @Europe/Berlin) and an offset, but I > also don't know all possible use cases - there could well be use > cases where you want/need to record both the location time zone as > well as the offset at the point when you recorded the timestamp. Time Zones vs. Offsets – What's the Difference? Which Is Best?: https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ Quoting: -------- - Given a time zone and a UTC time, you can know the offset—and therefore the local time. - Given a local time and an offset, you can know UTC time, but you do not know which time zone you’re in (because multiple timezones have the same offset). - Given UTC and an offset, you can know the local time. - Given a time zone and an offset, you don’t know much. - That’s why a calendar systems work with time zones, offsets, and UTC; - we need the offset to go from local time to UTC, and we need the time zone to go from UTC to local time. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/