From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 YE7kCI+ZxWNPAgEAbAwnHQ (envelope-from ) for ; Mon, 16 Jan 2023 19:38:07 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YGDhCI+ZxWO95QAAauVa8A (envelope-from ) for ; Mon, 16 Jan 2023 19:38:07 +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 C47553CE4A for ; Mon, 16 Jan 2023 19:38:06 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHULm-0005lQ-2O; Mon, 16 Jan 2023 13:36:54 -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 1pHULk-0005lI-9v for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 13:36:52 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHULh-0000o6-Oz for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 13:36:52 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id C91C9240143 for ; Mon, 16 Jan 2023 19:36:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1673894206; bh=+afaNiK8dZBIW1bEp1i6XubNkkx3xJKr5AAApsgN05U=; h=From:To:Cc:Subject:Date:From; b=QnDbeEU1veSAqLa02hDitt5Ry5NkE8O1HE87sk6HCjohi+vNO+AxOpq9/oaJ6ZAI2 tWqXnQ5Otc8RfuMpqaVZJzgN3y8xVH6bQZlauaL0jN4fmr+XzpRd/2zkTu5WjTic/7 OlXuVDy93CMQhvWANSpma82BW5kxJzkrmvZQzk7m+BEEw91x6cz0kGpVZRlWtAU6c6 RkFcdIKywjjRFOki5jsGfAL40VZRRt3WQ6wTFWxxsJoasLPY9SXbhFrn6NVykLU82b 1je4RBUDwmOzAhW5EL3Ap0DCNOSjDYuxyGeTnKgUxLQtGUFhrRSq7g+fPiTS6E0vqK oH8HMmS42D9dw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Nwgj75SnJz9rxF; Mon, 16 Jan 2023 19:36:43 +0100 (CET) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda In-Reply-To: References: <86zgamtv6o.fsf@gmail.com> <87tu0t1i0c.fsf@localhost> <87k01p1gvx.fsf@localhost> <87tu0rex01.fsf@localhost> Date: Mon, 16 Jan 2023 18:37:15 +0000 Message-ID: <87ilh6jpgk.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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-Seal: i=1; s=key1; d=yhetil.org; t=1673894286; a=rsa-sha256; cv=none; b=VrW1k2BfIFmWCFcxBGyMVIuFRKy+GIcryhSeFfN5tKFGZbO6HkGeXHqGDPC792+jE9oqFE OKZQLBF3xSY+P7QWp/O0zJ1TTVKBYO3oz+Z7VNn+bIfmmSYd87NJqexygy3cTNRGjhaNTH rUCbEo6DyDvEhCqVtrCYI7VN0YPusARUfaTQqHsXXZf+CRunRWo8ZBL0X+QBWnEyiXdFKQ 9DJgo4A+9eaOCrlAb0fdyxWl/e3EP9St4cu/jxrVCFC7uovyHyWEeETKKdXaLYafAASAiu UBolbLiZzDP0SFXyLygZgA8a99D+bmaklLCxxlObgzaH+0FKile/JgKEqAT5hg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=QnDbeEU1; 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=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673894286; 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:dkim-signature; bh=MFLRSvzBWmw2/Xl8EBk3RoyP1h/pC9FEWXCz4TFg0pM=; b=AOP6IMFOSyPV1apz90ehWaowkTfxX1Gzhim9vFqGogOKTOe/B+tXNARTP1r6Q46MBd4etb O4lI5GPkvAsKtnxqCHhH7JuFUYpsPX+a4etSrUW2eTrOqdmNQa7IZjSq5y3XCID9yVsT9T gqBvI+yWsFSQpf0iBKrH96xnr1t59bgI4CqUUYHRrITMhNjrv6QYESv7DesigKNWEZ1++P oPM7x/dGatyyb+MIYKHiSUaQHz4dy9DVyPcEPhJ2TkNopZjVwRdxYW8vcBEr/H5yZefsoV F/lKHSI+qPpCU7SZ5eOQZaRt0YsE+iQCSwiuuF2LSvUCx1OaPKhRkPTBpP9FYQ== X-Migadu-Spam-Score: -4.57 X-Spam-Score: -4.57 X-Migadu-Queue-Id: C47553CE4A X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=QnDbeEU1; 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=pass (policy=none) header.from=posteo.net X-TUID: 0frRLcEz+Osi Max Nikulin writes: >> Are you referring to one hour in year when the clock is moved one hour >> forward? >>=20 >> <2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute) >> <2023-10-29 Sun 2:01@-DST/Europe/Berlin> >>=20 >> I, however, do not feel like we need this +/-DST special notation. >> Chances that one needs a timestamp in this specific hour are slim. At >> the end, countries deliberately choose the time transition to not >> interfere with business activity. > > Yes, I do not mind to be able to represent 2023-10-29 Sun 2:01 before=20 > and after transition in the Europe/Berlin timezone. Notice that Python=20 > developers chose "fold" instead of "DST" for argument and field name: > https://peps.python.org/pep-0495/ > PEP 495 =E2=80=93 Local Time Disambiguation > > We should have this in mind, but I agree the priority is not highest one. I think we could allow the "double zone" idea I mentioned in another discussion branch: <2023-10-29 Sun 3:00+0200@Europe/Berlin> -> (+1 minute) <2023-10-29 Sun 2:01+0100@Europe/Berlin> Because 2:01 will happen twice that day, it will also be possible to specif= y=20 <2023-10-29 Sun 2:01+0200@Europe/Berlin> I think it is more intuitive compared to DST/no DST. And we do not even need to parse this scenario specially: The variants of the TZ spec will be: HH:MM@[^\n>\]]+ HH:MMZ HH:MM[+-=E2=88=92][0-9]{2}\([0-9]{2}\)? (note that I don't list times like 12:00+02:00 because it will interfere with time range syntax 08:00-09:00 is a time range, but might also be 08:00-0900 time zone) then, "@Europe/Berlin" in 2:01+0200@Europe/Berlin will be simply ignored and we will use the explicit UTC offset. >> I just tried: >>=20 >> (time-subtract >> (encode-time 0 1 3 29 10 2023 nil -1 ":Europe/Berlin") >> (encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin")) > > Pass list to `encode-time', not separate values in Emacs >=3D 27, since=20 > this case DST is -1 (guess) it is not important, but generally the value= =20 > is ignored. It is a pitfall in API. I see. This is not the only pitfall though. I just discussed the same issue with Tecosaur, and he noted that <2023-10-29 2:59@Europe/Berlin> is ambiguous because 2:59 occurs twice during that day: 2:59 -> 3:00 (DST -1 hour transition) -> 2:01 -> ... -> 2:59 -> 3:00 -> 3= :01 The fact that `encode-time' chose 2:59 after the transition is implementation detail. To deal with such cases, we may provide org-lint checker that will compare timestamps with t and nil DST parameter for `encode-time' and warn if there is a difference. (encode-time '(0 59 2 29 10 2023 nil -1 ":Europe/Berlin")) ; =3D> (25917 44= 628) (encode-time '(0 59 2 29 10 2023 nil t ":Europe/Berlin")) ; =3D> (25917 44!= 628) (same) (encode-time '(0 59 2 29 10 2023 nil nil ":Europe/Berlin")) ; =3D> (25917 4= 8!!228) (different) (encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin") ; =3D> (25917 48!!2= 28) (encode-time 0 59 2 29 10 2023 nil t ":Europe/Berlin") ; same (encode-time 0 59 2 29 10 2023 nil nil ":Europe/Berlin") ; same So, there is a gotcha with `encode-time' API, and we must use the list argument. (This gotcha is described in the docstring, but in rather cryptic way) >>>> <2023-01-14 Sat 18:22@+08> >>> >>> May become incorrect for future events due to updates of timezone datab= ase. >>=20 >> Emm. No? +8 is offset from UTC. It will not be affected by anything. >> Or are you referring to scenarios when user actually wants to specify the >> timestamp for specific country/city? Then the TZ variant should be used >> instead. > > Certainly events are usually associated with some area. I think, users=20 > will prefer concise +0800 notation to full timezone ID like=20 > Asia/Singapore and will get unexpected results sometimes. Manual should=20 > stress that fixing time offset is not a bright idea for planning. Sure. Having per-file/heading time zone settings will also help. I don't think that people will mind _occasional_ timestamps having Asia/Singapore. I'd personally prefer this kind of verbosity for overseas remote events. >> What I am essentially proposing in these examples is allowing: >> 1. TZ format as described in https://www.gnu.org/software/libc/manual/ht= ml_node/TZ-Variable.html > > Some formats may be confusing for users, e.g. TZ=3DGMT+5 actually means=20 > -0500 offset. Let's just recommend +-XXXX and @location in the manual. And mention briefly that TZ format is supported in addition. We might also provide an optional linter for GMT, if necessary. >> 2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_desi= gnators > > I do not see IANA identifiers here. Moreover currently there is no API=20 > to get list of IANA identifiers. On windows additional mapping may be=20 > required: > https://unicode-org.github.io/cldr-staging/charts/37/supplemental/zone_tz= id.html > > I do not mind to fix timestamps in past by adding offsets like +0100.=20 > For planning timezone identifiers should be strongly preferred unless=20 > time is really fixed in respect to UTC. Could you please elaborate? I don't fully understand what you are referring to. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at