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 MAlwGgMiYGLfNwEAbAwnHQ (envelope-from ) for ; Wed, 20 Apr 2022 17:08:51 +0200 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 yAo7GgMiYGLtDgEA9RJhRA (envelope-from ) for ; Wed, 20 Apr 2022 17:08:51 +0200 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 E7519128EB for ; Wed, 20 Apr 2022 17:08:50 +0200 (CEST) Received: from localhost ([::1]:57378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhBwo-00072t-4E for larch@yhetil.org; Wed, 20 Apr 2022 11:08:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhBvc-00070n-Cs for emacs-orgmode@gnu.org; Wed, 20 Apr 2022 11:07:36 -0400 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]:42985) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nhBvZ-0004qr-S1 for emacs-orgmode@gnu.org; Wed, 20 Apr 2022 11:07:36 -0400 Received: by mail-lf1-x130.google.com with SMTP id d6so3508008lfv.9 for ; Wed, 20 Apr 2022 08:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=NasT0/XDVAUDIhyHaGde84+YpYJrA6A9SbTjlKfsbSY=; b=du9wUvmoLgi8T4hYNDDE4mqEQwJUlHrs1NYGZ3yjRbm1DsDFiVCFAQhO+EdU514uvq I9d6wfrHyfZRd2+TMuQcWYCHvChwyNdRhKciIufHmZb4C1j49P+Ayf3JhEGPjW30fPoc Efc8erPwz93iM/y45ojWOjnOPb8E2D9zKL+zTgaZ1J9GuFJxCZCx+uYI9H6PyYadf2VN aC8isOBF4EOv4oIR5Shmkl7WixaaH99mhh0v5dVoFpSHzBM/ekQrWUvkcdsP7w16s5gq GShZVY+tQPy4oQBOewU/WnMzwqW02Xw0qhs/Jo0oMbfFrGxS2yfnOm8bYH2ze2S/DAt8 p8wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=NasT0/XDVAUDIhyHaGde84+YpYJrA6A9SbTjlKfsbSY=; b=7wmJFghFZXfr/0oUhcjc8mwEji+dj74Nkf3k6MQjR84JWgk2v/9Op2eHm8l7AbHpun mE6RkhTWSS7wLb5NFh5HGuWRUROuXxsl6N8JCi5x12Bk4dRrlvCET/gqr5/+TKOaDQL6 0NUQnlfE+7G0zUbknCWqBK8STR4xQ0Y31xLEZhgI02yX/fPaz23NzPLR6raJhRwC964H bU8YVfbauE0fdVXuFN6sJLTPILXSZIcdXW4HAS7dh/rOIxEVOZilDhizLLoZPSCJbs0Q ubnkPxljMtYJMLgJuLWNgCOVUEuFmAOp6U/JgKSswTjh8kfkaAIPOobJv8p9+7FLSUh3 RqIw== X-Gm-Message-State: AOAM531oVWWQeVDuENXbLqIBZIz2nrRJJ6ZfPhmIDlP0Lr7brE3a8nL7 9cGIODvsrjWWMUITuN1Rp2w= X-Google-Smtp-Source: ABdhPJx0zW1EA4xVVRmRkvORkeNQCEFctZZaZ4KVJr8kvq3BgCFRkBKkPFj2tiYRqb9Vt+ZXo0nJfg== X-Received: by 2002:a05:6512:214c:b0:46b:b4d6:989f with SMTP id s12-20020a056512214c00b0046bb4d6989fmr14958544lfr.572.1650467250530; Wed, 20 Apr 2022 08:07:30 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id p16-20020a056512313000b00471956e0bddsm897839lfd.49.2022.04.20.08.07.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Apr 2022 08:07:29 -0700 (PDT) Message-ID: <25d90a4b-f47d-01b4-2bfe-9951e97fe676@gmail.com> Date: Wed, 20 Apr 2022 22:07:28 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones Content-Language: en-US To: Paul Eggert References: <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com> <149de00f-115b-5367-414f-c7700ef8966b@cs.ucla.edu> <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu> <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com> <52fb10fb-892a-f273-3be8-28793f27e204@cs.ucla.edu> <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com> From: Max Nikulin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a00:1450:4864:20::130; envelope-from=manikulin@gmail.com; helo=mail-lf1-x130.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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: , Cc: emacs-orgmode@gnu.org, 54764@debbugs.gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1650467331; 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=NasT0/XDVAUDIhyHaGde84+YpYJrA6A9SbTjlKfsbSY=; b=tOG07ZUvKUZE392IhXAYfSNPcCajdsAKfeH35yDTzIp+EliIVAsG9d7CawplCU2hO6Ma0f VgXbPNfriolVmW+CZSY87Unv7/jv7svQHmakfCKFKM/LOHOYcSa3m9Ef+hXqv9PZRRaNfJ 5/YiDgelrd5N/T0xrlgimciqla4pjJwxRjxDc27GAJFR9NpHYiHZL0XTDs1xlSQKzWU4ti cW+Tz7g5iOWTo0iyN0Ta7r11rTu1h39EkKj8Pt5qBu3p8phbph/qVWfO5HlJPCnv9cZlEp s02uy5Ir1DTXNHYVbZ3DqfUgok9Scfe3ePkvr7tx/u3iNtUiVKU+KhA4p7hwxQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650467331; a=rsa-sha256; cv=none; b=tpldnsWX78iqP2B2+O7ryqf6t22ycqe9Mp8QPCIYvSpA6xPo6B2wx/UugVMeMHMrGbEw52 FpdY1N14TxcF3xn1Z72l/3fC7s2XkJW9j0VxxmHNpsS0wPvmJ5xqtlkeePWVlm8yQQuXJl +LNYvIdbWcEJTO266UMks1Rim+VTZN593aEgdKJ+kiHupZ/VGtE9VipOp0vEE385m6HHW/ PKta8m/+MdfX8wI8UGXI+QVAomBV4cQKEBUJWj2H3lwoG0aMN5RF9rQ9413aSo11TVklmB OqMOvrTWcofwYUNWBWgvh1rySUUgseTZyWI9tvZapTmCNeuRG4CMaietsoH75A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=du9wUvmo; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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" X-Migadu-Spam-Score: 5.36 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=du9wUvmo; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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" X-Migadu-Queue-Id: E7519128EB X-Spam-Score: 5.36 X-Migadu-Scanner: scn0.migadu.com X-TUID: L93DOPhgvpWY On 19/04/2022 09:02, Paul Eggert wrote: > Here are the main points I see about making timestamps work better in > Org mode, and related patches to how Emacs handles timestamps. > > * Max would like encode-time to treat a list (SS MM HH DD MM YYYY) as if > it were (SS MM HH DD MM YYYY nil -1 nil), Thank you, Paul, it is exactly what I had in mind when I created this bug. > as that would be more > convenient for how Org mode deals with ambiguous local timestamps. This > is relatively easy to add for Emacs 29+, and is done in first of the > attached proposed patches to Emacs master. I would say that Org just does not care concerning ambiguous local time. Anyway there are other similar cases besides DST. > * As I understand it, Max would like a function that emulate Emacs 29 > encode-time with one argument, even if running in Emacs versions back to > Emacs 25. I suppose such a function would also need to implement Emacs > 27+ encode-time's support for subsecond resolution. E.g., > (org-encode-time '((44604411568 . 1000000000) 55 0 19 4 2022 - -1 t)) > should return (1650329744604411568 . 1000000000) even in Emacs 25 and 26. I am just afraid of possibility of recurrent attempts to modernize time-related code within Emacs including Org code in a such way that can not be directly ported to the Org repository. Discrepancy of the code increases maintenance burden. The main purpose of a compatibility wrapper is to prevent grep-driven refactoring. Another point of the helper function is to allow to remove from Emacs support confusing old-style `encode-time' arguments with ignored DST value. In Org timestamps are often built from scratch, so separate argument are still convenient. Org timestamps have minute precision, even seconds are trimmed. So at least explicitly I did not ask for subsecond timestamps. I admit however that they might emerge in some code paths. Notice that nobody from Org developers & maintainers commented the patch demonstrating the idea of such wrapper. > * My last topic in this email is Max's request for a feature that I'm > not planning to put into Emacs 29 as it'll require more thought. This > addresses the problem where your TZ is "Africa/Juba" and you want to > encode a timestamp like "2021-01-31 23:30" which is ambiguous since at > 24:00 that day Juba moved standard time back by an hour. Unfortunately > the underlying C mktime function does not allow disambiguation in the > rare situation where standard time moves further west of Greenwich. > Addressing this problem would require rewriting mktime from scratch in > Elisp, or using heuristics that would occasionally fail, or (my > favorite) extending glibc mktime to treat tm_isdst values other than > -1,0,1 to support disambiguating such timestamps. I do not urge such changes. I have not checked if mktime is a part of POSIX and C standard. If it is so, I am not in favor of adding more values for the tm_isdst field since they are not related to DST. I started this branch of discussion to convince Paul that requirement of 9 fields is not really encourage more correct usage of `encode-time' in comparison to 6 values. More convenient interface for processing of local time moments requires significant amount of work, maybe some prototypes. It should be considered separately from this bug. I still believe that optional DST and ZONE values is an improvement of the `encode-time' interface with no real drawbacks. It minimizes the chance of passing nil as "no DST" when actual value is unknown and developers are not ready to add a bunch of code to determine proper TZ offset for each case of time transition.