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 aMEPNRl/xWP8YwAAbAwnHQ (envelope-from ) for ; Mon, 16 Jan 2023 17:45:13 +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 gMgiNRl/xWP6CAAA9RJhRA (envelope-from ) for ; Mon, 16 Jan 2023 17:45:13 +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 6387428F7F for ; Mon, 16 Jan 2023 17:45:13 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHSai-0002zP-9u; Mon, 16 Jan 2023 11:44:12 -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 1pHSaf-0002xd-ST for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 11:44:09 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHSae-0004ID-6A for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 11:44:09 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pHSac-0009mL-5h for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 17:44:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Mon, 16 Jan 2023 23:43:58 +0700 Message-ID: References: <86zgamtv6o.fsf@gmail.com> <87tu0t1i0c.fsf@localhost> <87k01p1gvx.fsf@localhost> <87tu0rex01.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US In-Reply-To: <87tu0rex01.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 27 X-Spam_score: 2.7 X-Spam_bar: ++ X-Spam_report: (2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.097, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=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-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=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673887513; a=rsa-sha256; cv=none; b=LBBA1PpJ9OfAz+B4/cloVzrilr0Fzd5q4s4bXNrWbB9dNUAPMWZ8QgMckw5IPjXpIG8ngL MQ4Opbfer1p4b3DBOeO3QcN2PVpvmRcVTXiJFCq9R0tHYALeaGCkBRRQ4+Ogifg6dXXpDV 5JMItuk1ia/4w/f1V9UkPU0SeCtcQLTekte6v4zAo8LqXFe/Lk6UhtYqp5ZoYLt7eVrFCK EhvUnZ7yi0+M5Ok/kCzLKOdjo+PRQ7ONEPHRuUPzjF7wx9znMBFsuDsrc+1Z+DFEycCR3P T/G/2aV+WnfT9qEWDrpTFDrlBR/coksdAksHed2Dac9Gh93zOVYcJy+f/NUs0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673887513; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=X+1LbYlMDnwFx5irT1NHtyp/1c71+8Wpi0KDXN0yxDc=; b=bqRwX6wKk54mATjQ3tAjjEipTJ1/0sqUQOY14+Y25ogUP5v+MNUuqf1dTRbeD4KLoaAadt sIB0CDL5kGxqRkQSGMCuuAjDptgG6/D/NqMXVlB2IAW3Fb29g4dZle91RWDysjlB4JPi+k jOOoUGCqJb8wpFIuU1Ph3I8Zl6L+L8oFINTq7/kyxwdR+rIsJjoSSS7v9G3SIyI/SXr2nn amTyeNSBDO0s+O2e+9nkYpvIBMAsYVpFpskkdiAH/zWPMEkxbkd1NX2n+LCbMpxJ5miw+D cSqi3/SVx644A45sC/BEk4xQiLEuX70W8OpuVAevlFLFXDOsw/lI+WqmaCl3Dw== X-Migadu-Queue-Id: 6387428F7F X-Migadu-Scanner: scn0.migadu.com 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=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) X-Migadu-Spam-Score: -1.33 X-Spam-Score: -1.33 X-TUID: xG8tLeijUxHG On 15/01/2023 20:41, Ihor Radchenko wrote: > Max Nikulin writes: >> On 14/01/2023 18:42, Ihor Radchenko wrote: >>> >>> <2023-01-14 Sat 18:22@Asia/Singapore> (SGD and similar abbreviations are often ambiguous) >> >> Such format is ambiguous for timezones with DST around backward time >> jump. Before/after time transition should be specified in addition, e.g. >> by combining identifier and offset or some way to state namely before or >> after. > > Are you referring to one hour in year when the clock is moved one hour > forward? > > <2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute) > <2023-10-29 Sun 2:01@-DST/Europe/Berlin> > > 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 and after transition in the Europe/Berlin timezone. Notice that Python developers chose "fold" instead of "DST" for argument and field name: https://peps.python.org/pep-0495/ PEP 495 – Local Time Disambiguation We should have this in mind, but I agree the priority is not highest one. > I just tried: > > (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 >= 27, since this case DST is -1 (guess) it is not important, but generally the value is ignored. It is a pitfall in API. > (see https://www.timeanddate.com/time/zone/germany/berlin) You can inspect your local database zdump -v Europe/Berlin > and it looks like the expected return value should be 1 hour 2 minutes > (3720), but it is not, on my system. it is assumed that you should explicitly specify DST to get another branch (but at first you should determine somehow at which side DST should be applied): (let* ((tz "Europe/Berlin") (t1 (encode-time `(0 1 3 29 10 2023 nil nil ,tz))) (t2 (encode-time `(0 59 2 29 10 2023 nil t ,tz)))) (list (format-time-string "%F %T %z %Z" t1 tz) (format-time-string "%F %T %z %Z" t2 tz) (time-subtract t1 t2))) ("2023-10-29 03:01:00 +0100 CET" "2023-10-29 02:59:00 +0200 CEST" 3720) Actually behavior is more funny, but I need more time to investigate it more close. The real problem with libc is that TZ DB contains time transitions preserving DST value and DST argument of `encode-time' becomes useless: Europe/Kyiv Sat Jun 30 21:59:59 1990 UT = Sun Jul 1 01:59:59 1990 MSD isdst=1 gmtoff=14400 Europe/Kyiv Sat Jun 30 22:00:00 1990 UT = Sun Jul 1 01:00:00 1990 EEST isdst=1 gmtoff=10800 zdump -v Africa/Juba ... Africa/Juba Sun Jan 31 20:59:59 2021 UT = Sun Jan 31 23:59:59 2021 EAT isdst=0 gmtoff=10800 Africa/Juba Sun Jan 31 21:00:00 2021 UT = Sun Jan 31 23:00:00 2021 CAT isdst=0 gmtoff=7200 >>> <2023-01-14 Sat 18:22@+08> >> >> May become incorrect for future events due to updates of timezone database. > > 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 will prefer concise +0800 notation to full timezone ID like Asia/Singapore and will get unexpected results sometimes. Manual should stress that fixing time offset is not a bright idea for planning. > What I am essentially proposing in these examples is allowing: > 1. TZ format as described in https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html Some formats may be confusing for users, e.g. TZ=GMT+5 actually means -0500 offset. > 2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators I do not see IANA identifiers here. Moreover currently there is no API to get list of IANA identifiers. On windows additional mapping may be required: https://unicode-org.github.io/cldr-staging/charts/37/supplemental/zone_tzid.html I do not mind to fix timestamps in past by adding offsets like +0100. For planning timezone identifiers should be strongly preferred unless time is really fixed in respect to UTC.