From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id PpebMnmzWWJ6EAAAgWs5BA (envelope-from ) for ; Fri, 15 Apr 2022 20:03:37 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id uJ90LnmzWWIl6AAAauVa8A (envelope-from ) for ; Fri, 15 Apr 2022 20:03:37 +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 5E504BC15 for ; Fri, 15 Apr 2022 20:03:37 +0200 (CEST) Received: from localhost ([::1]:49364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfPgK-0007an-SG for larch@yhetil.org; Fri, 15 Apr 2022 13:24:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfPfL-0007ad-HP for emacs-orgmode@gnu.org; Fri, 15 Apr 2022 13:23:27 -0400 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:35508) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nfPfJ-0006kg-Fa for emacs-orgmode@gnu.org; Fri, 15 Apr 2022 13:23:27 -0400 Received: by mail-lj1-x22b.google.com with SMTP id h11so10152050ljb.2 for ; Fri, 15 Apr 2022 10:23:24 -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=xMVBKuJeF02+Y270FbNaEJgQcYOZ/XERtYPQm8DAP5g=; b=HdLPoix02it9lqXUS/mI5KGcS3xWxluUJjHU8TcKyr5RTO1QurGRJeQcvgWUtrgLea eK/L/CoB8qL5AyiqaESiTd0w+wIxpgH/m86SiIBJntDHfajiqi/cAehNkISqM+oVw88E 1oyWSUmddyLKcnmb92sr9ND5B75Xd5PFLzuw9R9Mf6JFmLSonTDy/U8eRl+dAyQbGAHu FePVPtH7bjVISlZ7sZt2Z9w8BaK73vf7n5KgyAY/OqGnTW6uQ/uFtOJn/vRd47w9Tujk P0gxYWt9pJ3LpmBEA1QFKlqzy7khpjuXREJe/Q8RVC0JG90SqgmPRxOLhMxhYS+unNxS snEA== 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=xMVBKuJeF02+Y270FbNaEJgQcYOZ/XERtYPQm8DAP5g=; b=GJXt9z8Q6ZCg65qSQxtJzrc1TNGpwBcT2+Yb+lOyJaHIyX6bRYiF5r6FCDinM1+jec 5TKXLJSlz3RgVEDzdtp3VFxkZSCEHjGDJ7+EwZ+z7DZqc2dxPSZq2VFgmYx45vkM+Jhu yoWQJITwu1tc1gKOVVH++stTyA+NT+Et+1vPU4HAwnt1eKTyJUHS4nSViaJIlN/QtXkJ KtbSqEOy2iIgpqkkwsEviuMl0T8UI8bEDgL3agp4JUoxnpDi8zJc5vvusbTheN3T1jBJ Xb0xJ57JgSNvInUGK+kAl7T2Dx9/gJM0gBsWW+ojG+ojWBozWGj5R2tt34FEiKQBEvJ7 lxTQ== X-Gm-Message-State: AOAM530M9oaZ0o4sw+BlsdYVS/auSydBBON3U9NxFpsxlCE9Of0PBwZ0 SF0J5i7gOKHb9pPSLjvgVqE= X-Google-Smtp-Source: ABdhPJwh/gTCmaxJz9AE8pmAxbDMse6WCHeFRZOWEYZVtE8E0r5V5iEq6NT0MIRKFqJDZnRGE2VRhA== X-Received: by 2002:a05:651c:19a5:b0:24c:87dd:d60d with SMTP id bx37-20020a05651c19a500b0024c87ddd60dmr93495ljb.344.1650043401821; Fri, 15 Apr 2022 10:23:21 -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 n2-20020a056512310200b0046e2f507a3asm375858lfb.167.2022.04.15.10.23.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Apr 2022 10:23:21 -0700 (PDT) Message-ID: <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com> Date: Sat, 16 Apr 2022 00:23:20 +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> From: Max Nikulin In-Reply-To: <52fb10fb-892a-f273-3be8-28793f27e204@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::22b; envelope-from=manikulin@gmail.com; helo=mail-lj1-x22b.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=1650045817; 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=xMVBKuJeF02+Y270FbNaEJgQcYOZ/XERtYPQm8DAP5g=; b=jExqikVK3qXtCOyJs7ZNOknYNcXvX2OtIXBjqeEb8HtmQRdM12LPcXgmR0K49gtECmQWpK 0CeAxnrWhzCfAYAb0FU9SvuPUHpM0sBy7/DIAXuN0uqqNSlZaB8920xdvyoBWsPoFOOIJH m1tBNanijN6bCy8YgBBfl/PU5jdWHaqtxTyimnLJHXuO4UzCOE0SfXOTT35wvdeDIbgEc0 cDE62Dyt51oFxzcametJ1o35NmFP5Y0ThMw6bXyjj4ygIfmkQAwRhBgm0ChChEZzk5YgyE TikKfezN8pyGALzW8D11rE7+4sXfZXGnP5s0p+m7h9YhzMWs/EcW/ef+J3mO4w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650045817; a=rsa-sha256; cv=none; b=DBP1uZPdO8/vIDo2ZYJ03hMOFYRSWt+b4VGZKGPVDUFGYn2bL4tgN+311kygNbDHltLT6K D5S5M9gNCNncPzR89u9+VuvF3gkqkmcVnuRgZbtkRrsdLfSRVjIpGOm5iSqU/HAjorGNxE jDcV7IGFjGOhLD6gZk6s9EsbTYA757LtfD8UfGYxfrPESVGPygondaWg79N61nI7Zy9rDr PPNlPQdYkYH4vemLuKQ6uAB/naTCOLA4RRmSc9dSBH2E79lSjlLDv8Ga6+HsaFeuagD1ct due6Ea/+H0GybSN4sZiajSokqS8bELa2lAMFWY2XnwCu1FQuXgU4Gg8uosRmRQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=HdLPoix0; 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: 7.36 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=HdLPoix0; 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: 5E504BC15 X-Spam-Score: 7.36 X-Migadu-Scanner: scn0.migadu.com X-TUID: F1idBCjA0kEb On 15/04/2022 05:46, Paul Eggert wrote: > On 4/14/22 06:19, Max Nikulin wrote: > >>  date-time + "America/Los_Angeles" input should not be reduced to >> timezone offset in the output. > > It depends on the application. For some applications (e.g., generating > "Date:" lines in email), it is entirely correct to output a timestamp > like "14 Apr 2022 15:16:04 -0700", thus losing the fact that the > timestamp was generated with TZ="America/Los_Angeles". However if you are storing future events bound to wall time then namely time zone identifier should have precedence. A new rule may be issued between scheduling event and the time it will happen. It is terrible feeling when it is necessary to guess if a web site stores TZ offset or its identifier and in the latter case whether its administrators updated tzinfo. It is better to store location of event since a time zone may be split and time transition may apply only to a part of the original zone. Actually I meant another case. Some representation is got for a time moment and it is necessary to get local time for another time moment. Time zone identifier or an object with internal representation allow to get correct offset for second moment of time. It should be possible to specify whether a function call is isolated conversion or further calculations will follow. >> Zone internal object or identifier is important for calculation of >> other date-time values based on the origin value. > > Again, that depends on the application. It's typically wrong to store an > old timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because > there is no standard for what "Europe/Lisbon" means. If you update your > copy of TZDB, or interpret such a timestamp on another computer, that > can change the interpretation of such a timestamp. In this particular > case, a change in TZDB release 2021b altered the interpretation of this > old timestamp because we discovered that DST was observed in 1950 in > Portugal. Just identifier may be ambiguous around DST transition. So timezone abbreviations are ambiguous per se but when identifiers are known they may be still necessary to resolve uncertainties for backward time shifts. At certain moment the Olson DB started to use "+04" abbreviations instead of letters for transitions unrelated to daylight saving time. > If you want to keep the TZDB identifier for advice about how to > interpret dates relative to a timestamp, that's fine. But you should > keep the UT offset in addition to the TZDB identifier, if you want your > app to be fully accurate and useful. For example, you should store > "1950-07-01 00:00:00 +0000 Europe/Lisbon" for a timestamp generated by > TZDB release 2021a, so that when you interpret the timestamp in release > 2021b you'll have an idea of what you're dealing with. And WET/WEST gets another bit of info in addition to numerical offset. >> I hope, they may work without explicitly providing time zone offset to >> the input that anyway requires additional calculations. > > It doesn't require additional calculations on the Emacs Lisp user's > part. All you need to do is save the UT offset, and use it later. > There's so little overhead to this that it's not worth worrying about. I do not remember if it is possible at all to obtain using libc the period of constant time offset, when time shift value is valid. Sometimes it is necessary to recalculate offset. >> ±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. > > Sorry, I don't understand what this sentence is intended to mean. Let's consider Australia/Lord_Howe with 30min backward DST shift at 2022-04-03 02:00. 8 hours from 2022-04-02 22:00 may mean 2022-04-03 06:00 for duration of the night shift (8:30 instead of usual 8:00). Some technological process requiring precisely 8 hours finishes at 05:30 in such case. So it is not equivalent to add 8 hours or 480 minutes. In the former case it is more convenient to increment particular field and adjust the result if it coincides with ambiguity/impossible range. In the latter case it is better to increment timestamp as seconds since the epoch and back to time fields (leaving aside leap seconds). >> `parse-time-string' has another set of problems. > > Sure, but that was just an example. You can write your own date parser. > The point is that when you save a localtime timestamp, you should save > its UT offset too, in whatever notation is appropriate. You wrote that "2021-01-31 23:30:00 +0300" is parsed correctly. My opinion is that when time zone is known to be Africa/Juba (system-wide setting, environment variable, or an argument of the parsing function) then "2021-01-31 23:30:00 CAT" and "2021-01-31 23:30:00 EAT" should be parsed correctly (and localized date-time formats should be parsed as well). For transitions without DST change there is no conventional text representation. >> 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. > > I doubt whether that's a good idea. I've written that sort of code, and > it's a lot more work than one might think and it's notoriously difficult > to do it correctly. You have better things to do. Elisp implementation of date-time library is not in my TODO list. I just know that there are enough implementations already (and some of them may be/was buggy): - https://github.com/moment/moment-timezone/blob/develop/moment-timezone.js and currently browsers should have their own implementations - https://github.com/php/php-src/blob/master/ext/date/lib/parse_tz.c - https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/time/qtimezoneprivate_tz.cpp - https://github.com/HowardHinnant/date/blob/master/src/tz.cpp and I have heard of more libraries. There are a lot of corner cases, so "universal" rules will unavoidably fail. Flexible API may alleviate some cases. P.S. Once I noticed the following comment on stackoverflow: Cubbi Jun 12, 2012 at 22:26 > std::broken_promise is the best named identifier in the > standard library. And there is no std::atomic_future. https://stackoverflow.com/questions/11004273/what-is-stdpromise mktime(3) man page uses "broken-down time" term for struct tm. It explains why it is not unusual when code dealing with time is broken.