From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id EJsgL2sfWGLaCAAAgWs5BA (envelope-from ) for ; Thu, 14 Apr 2022 15:19:39 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id wJ2OLGsfWGIb+wAA9RJhRA (envelope-from ) for ; Thu, 14 Apr 2022 15:19:39 +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 49797E2DC for ; Thu, 14 Apr 2022 15:19:39 +0200 (CEST) Received: from localhost ([::1]:54844 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nezNq-0001aa-Bn for larch@yhetil.org; Thu, 14 Apr 2022 09:19:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nezNO-0001ZF-RQ for emacs-orgmode@gnu.org; Thu, 14 Apr 2022 09:19:10 -0400 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:40957) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nezNM-0007Y6-Or for emacs-orgmode@gnu.org; Thu, 14 Apr 2022 09:19:10 -0400 Received: by mail-lj1-x229.google.com with SMTP id m8so5983556ljc.7 for ; Thu, 14 Apr 2022 06:19:08 -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=pmiyCfaKtoLb5GO/yT7sGNWW6EI28ufgGlHhNOoNHAI=; b=oR37Fs05z0brXuqW7BYrwzFY4wf5amRI/UU1pihvL2pu8570zM0Rb2gdGUEsDN6LzH xXUJNSUohkfMoT0fq8898uHGSwJKIYY8/wLEJBHhLKwKqaywpJMC/TdXgqfm+Eh/b/wV K436iBHsZ8U9hO1d4UZDyilh42HGKgZgbehlKrNjp3t3srmwdqnHj8PFol61F9xppTZz uAhcnjpLW6y8duzQqle1eOMXY5Rngf86pL0nbb507v0tLLVpzll9P1SHlDfM3YRjCbH3 vm1By8CJnRdTHAM70jNSVc3aRSqMqCKCv1a1d/LPRaxvvPO1JkWc7I2Jap+Q7hJy7ggl 25zA== 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=pmiyCfaKtoLb5GO/yT7sGNWW6EI28ufgGlHhNOoNHAI=; b=4g8ORWj46UCLXLBnzj2r3WA/wy9gUWAylu8FpubTTn5nJmZE0QhRcE3WJSvtnSGsjA MKIZH3soRIEXxaJ6F1IlEmieWDThtb0hQbOxicflicR3Qir1ZIVUp/o96JYSZRJ/dWc+ U1JewEh2XNLhS9xGWQxA2+cCE3obl81IzdLFc8oguLDZpl5ermsbG1KC5o3h9Je6ZWa+ X3Uhrh1SDckhKkSlJPABjE8mtzSCq4S3jH3B31mRZvZiU7FgUpFNjMv0aL/jcQ7nzPuv sPuIkFPWFhw2sTTkdolgg4voOfhUxAvZ9JgqKF3emm2eDAW4mikUumvhR+OssBrFkeiE HDtg== X-Gm-Message-State: AOAM532laWVqDXlC63V4Dc40VkXeYQ0gAUk5wHjbiFXI2eKyhLtiuALb uXf2os5gDqd1kKhrvfzWUFg= X-Google-Smtp-Source: ABdhPJx6cOTVmGDCJsmCefgAQQHJ+Srp3XJEoXEmdHyOEQgR5N3lQal+GfqT6sri4Xw0+RY97S57Cw== X-Received: by 2002:a2e:bf01:0:b0:247:dfe7:62dc with SMTP id c1-20020a2ebf01000000b00247dfe762dcmr1575175ljr.365.1649942346472; Thu, 14 Apr 2022 06:19:06 -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 z19-20020a19e213000000b0046d052030aasm243472lfg.66.2022.04.14.06.19.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Apr 2022 06:19:05 -0700 (PDT) Message-ID: <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com> Date: Thu, 14 Apr 2022 20:19:04 +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> From: Max Nikulin In-Reply-To: <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::229; envelope-from=manikulin@gmail.com; helo=mail-lj1-x229.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=1649942379; 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=pmiyCfaKtoLb5GO/yT7sGNWW6EI28ufgGlHhNOoNHAI=; b=rA9dMWGUVOQEgvr1yPop8Njt9COxBpHvXeLAAJxV/X4mKCJ1bMhJqVWxcNcDNotQfVC5Tg q1KGMh39eAv6yg9qd2pRiZRpmC2BNmu16d54wnzYvqGp8KMOAHZH6kI0Tcl7IiBNJTMboX AjPhCt3dteHDVk1ZzPCARw2mR/LZe936PUjB1p1Eb/PY8wuc5afjfbXl0a4uCvqQgBfKuC 81lNr7c7vkFiWmyCs5At0O1DqB8iJHp1NT+vv5DIjpK1dQ19CB0qVojlwa5sJ16QrtBY7T JIauu448DOyYrlMyu/m0GzE9S8Gn3nvEL84bjt9mps69TgpVDKb8ROQKmY+GVA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1649942379; a=rsa-sha256; cv=none; b=DavKpCb0kq1p+vzYVGGswsBKg9Yz6lisbL8GD/3JPdoqaSXXtnFGjYdj77ddVu+fYTxUY/ GDQrhHNWp52zA0jQsbcDGfOMK6tSQF1N5s3FiYqW/EtTNQEgLA3KpINtjj+6mBJ3kfuyVb IK9m6gkMYFAaQB2f9Abhw0xbFRnR/YaK2EJ8GQNBIXtKZT/C/y3pSe6oWz9ABVIzxta/b4 pU8jOrj1HKaYLaqXEWrPMbI2QvLtefP7uoAedfQjHgsSS4T8dAkyLwofa9Hgh7fOcTc2MX 9wIqd7NulQra7MvWCpt7FHEhMO9laYrG34BufFin3wkeuvmQjoKs4VemGLancA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=oR37Fs05; 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: 6.15 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=oR37Fs05; 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: 49797E2DC X-Spam-Score: 6.15 X-Migadu-Scanner: scn1.migadu.com X-TUID: TML0GVCdymjO On 14/04/2022 01:35, Paul Eggert wrote: > On 4/13/22 07:40, Max Nikulin wrote: >> >> I do not see a way to get 23:30 EAT +0300. > > Are you asking for a function F where you say, "I want to give F a > possibly-ambiguous decoded local time D, and for F to return all > timestamps that map to D"? If so, encode-time doesn't do that, because > the underlying C API (namely, mktime) doesn't do that. All mktime and > encode-time do is give you *one* timestamp that maps to D; it won't give > you any other timestamps. I am just trying to convince you that new API still can not handle ambiguities in response to: >>> Unfortunately it makes the function more convenient to >>> use incorrectly. This was part of the motivation for the API change. >>> The obsolescent calling convention has no way to deal with ambiguous >>> timestamps like 2022-11-06 01:30 when TZ="America/Los_Angeles". Completely ignoring DST in old API is a bug. Possibility to omit DST and ZONE is a feature for convenience and it is not related to correctly/incorrectly. It has no common with allowing 6-values SECONONDS...YEAR list. I am aware of mktime and my opinion is that libc in such cases (dealing with formats for humans) is hardly usable for applications more complex than "hello world". I do not want all ambiguous time values. I want to provide hints how they should be resolved and get in response an additional value that says in which way it is actually resolved. > If you're worried about possibly-ambiguous decoded local times, you > could probe (say) one day before and one day after encode-time's result > to see if the UTC offset changes, and let that guide you to find other > possible timestamps that map to the decoded time. Although this is just > a heuristic it should be good enough. I would prefer to avoid dances with +/-1 day timestamps. I would not be surprised when one day they will give wrong result. During computations it is available to which interval of time current time offset is valid. Such value may be included in result of conversion. So date-time + "America/Los_Angeles" input should not be reduced to timezone offset in the output. Zone internal object or identifier is important for calculation of other date-time values based on the origin value. > I doubt whether you need to do that, though. Code that is not careful > about local time offsets doesn't care how ambiguous decoded times are > resolved. And code that does care should record UTC offsets anyway, and > you can use those offsets to disambiguate the decoded times. Something > like this, say: > >  (defun encode-and-format-time (time tz) >    (let ((etime (encode-time (parse-time-string time)))) >      (format-time-string "%F %T %Z %z" etime tz))) > > With this definition, (encode-and-format-time "2021-01-31 23:30:00 > +0300" "Africa/Juba") yields "2021-01-31 23:30:00 EAT +0300", which is > the timestamp you want. I want hints like "in the case of ambiguity resolve to transition time immediately before/immediately after transition" or "provide suitable time prior to/after to transition". I hope, they may work without explicitly providing time zone offset to the input that anyway requires additional calculations. ±n hours may mean ±n*3600 seconds or time with same minutes and seconds values but hours value is changed by n even if a 30 min DST transition happens in between. If agenda interval start falls on skipped time span in local time then the value immediately after transition should be used (and maybe user should be warned by additional entry). For agenda end interval vice versa local time immediately before transition is more suitable. `parse-time-string' has another set of problems. It is impossible to specify particular format like for strptime(3). Actually parsing a string to numerical values and resolving ambiguities in numerical values are different tasks and it may be useful to have separate functions for them. I am unsure however concerning implementing constraints to parse free-form dates. >> `encode-time' should only accept time zone as time offset and should >> not allow default or named value that may be ambiguous. > > If we're talking about Org's encode-time substitute, you can of course > do what you like. But Emacs encode-time has supported ambiguous > timestamps for some time and I expect it's used by apps that don't care > how ambiguous decoded times are resolved, which means we shouldn't > remove that support without having a very good reason. There is no reason to impose such restrictions for helpers in Org since Org relies on resolving ambiguities with minimal efforts. `encode-time' supports just one kind of ambiguities. Even though it is the most common one, it is rather (partially false) impression than real support. The truth is that most of developers are not aware of real complexity of dealing with time. Documentation rarely describes limitations and corner cases that should be handled. Even when correct time handling gets more priority it appears that available libraries are full of bugs and require ugly workarounds. >> should be possible to provide hints to `encode-time' to get >> deterministic behavior in the case of time transitions > > Yes, that feature is already there. The hint is the UTC offset, as > illustrated above. No, UTC offset is another feature and implementing the hints I have tried to describe may require implementing from scratch full stack of time handling functions. In some cases offset should be replaced by time zone identifier to avoid incorrect result in further calculations. So I still do not see any point in mandatory DST and ZONE fields in new interface of `encode-time'. I do not see an alternative to convert SECONDS...YEAR values to timestamp assuming local time zone as well. Anyway DST is not available in advance and sometimes DST value is not coupled with step in local time, so its ability to resolve ambiguities is limited.