From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 0MvlBSDt2WPHMQAAbAwnHQ (envelope-from ) for ; Wed, 01 Feb 2023 05:40:00 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id kBfpBSDt2WPfZgAA9RJhRA (envelope-from ) for ; Wed, 01 Feb 2023 05:40:00 +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 C2D7AEB66 for ; Wed, 1 Feb 2023 05:39:59 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pN4tl-0005CF-Sz; Tue, 31 Jan 2023 23:39:05 -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 1pN4tk-0005BU-3M for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 23:39:04 -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 1pN4ti-0005Mv-FM for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 23:39:03 -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 0000000000103A91.0000000063D9ECC9.0000164A; Tue, 31 Jan 2023 21:38:33 -0700 Date: Tue, 31 Jan 2023 23:12:00 +0300 From: Jean Louis To: Ihor Radchenko Cc: Greg Minshall , Sterling Hooten , "Thomas S. Dye" , Tim Cross , Daryl Manning , rjhorn@alum.mit.edu, 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 , Greg Minshall , Sterling Hooten , "Thomas S. Dye" , Tim Cross , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org References: <63c9d976.620a0220.a7d40.113b@mx.google.com> <87tu0mjb24.fsf@tsdye.online> <63ca1283.170a0220.5bc81.0fdd@mx.google.com> <87pmb9k8oi.fsf@tsdye.online> <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> <87lelo8c9r.fsf@localhost> <2150768.1675077958@archlinux> <87tu063ox2.fsf@localhost> <87h6w63jgg.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87h6w63jgg.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: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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=1675226399; a=rsa-sha256; cv=none; b=RUoHOw8cGLYaezytY/KpUlBdkUP36gLDzSzdkXka9Sz+zezHLMR8hNsftJmqhfqcnm8zPw czr1wP0L/8yrMLsAcI6sztjtrXPibzOdXON1b9mf7VglSyce/sP2Si5keAnqXo9i2utEug CkBduZcHm0qp1V0D/HFPyeayYLzpjv99HZX2HD5ngGgFEzzjyTefqoBVzkSRsk0CPC9XQ3 WR5/OLsFoRkHTnAJADAuOhzn3xVckSys6GxDot78FArDfLYlauU0Bba32lMVlfl5UF6JJD o0QCdoukjGVXNWkIRHUAEUDMZaE7JYIZ5ccdHkO4/TuOoCQhp2yYgJOnCR1NjA== 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=1675226399; 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=tMSsYfBabG2l+T31DMHTKRfjWgEeysLwFCAALyvgbic=; b=esUeKPqpMw1SEeH2ytT7wQB1rJkTRd9oG3HO+b+hwyVfKFS/P6pz2oqJIrRmpgwTTyDicr A3rnqaD63zffXt+nt0J23qAh4Ts31F3rLdAL7irdNOltxQr4C59KNuGEflMqHHiQb194Y8 +vBPs25M4s8an9CqH/4pW1MA0l/FATLNW8CUHu4CAUfy2KugbqIbZWTK0hkacEzwQKaAUt Db1xoaGPB4uHHWP+kXB8ePZCNlYXEHQSlNIeyrwk1epMcHEVfzBlHlulYjWMrGt/8PQoIz tcUX+8Q3JVY5U5aTtrUfzFOm/RphWBIBmtdkMnpdEMjMFbaAuzZEx1YUIZAvfQ== 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: -0.88 X-Spam-Score: -0.88 X-Migadu-Queue-Id: C2D7AEB66 X-TUID: JbR804gFK3tc * Ihor Radchenko [2023-01-31 16:46]: > Specifying just @Europe/Berlin is ambiguous around the daylight savings > transition. Sorry, I cannot see practical example why is it ambiguous. Unless programmer does not take all information in account, it is not ambigous. People on this planet agree on time zones in advance, so there are few changes that people cannot plan in advance. Those changes are recorded in time zone databases. Unless you consider programming without using time zone databases, then I can surely understand that it will be ambiguous. > To resolve the ambiguous, we should either introduce DST flag DST is property of time zone. You do not introduce it, you read it from time zone database. But maybe you wish to implement time zones in Org. In that case I can only say "Good luck" to accuracy. > or simply allow specifying the UTC offset directly. UTC offset is not reliable, and is also derived from time zone database. Try it out, make tests, create experiments, compare if that approach will be usable, publish it and put in for testing. > Since DST is not guaranteed to be +-1 hour (it may be more, up to 1 > full day), DST flag is more problematic than UTC offset. Is not if you always pull the latest tz database. Political changes are pretty careful to people and decisions are announced ahead of the change. So do you think that you cannot use tz database in Emacs Lisp? Maybe it will be necessary to make new Lisp functions defined in C language, accessing the time zone database. But it is not for Org to implement new tz database in Emacs Lisp, that will become unmaintainable work. But why not, if you wish, but accuracy of time will be questionable. Researching following pages will give you idea with what you are trying to deal with on Org level: How to Read the tz Database: https://data.iana.org/time-zones/tz-how-to.html List of tz database time zones - Wikipedia: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones tz database - Wikipedia: https://en.wikipedia.org/wiki/Tz_database -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/