From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxim Nikulin Newsgroups: gmane.emacs.bugs Subject: bug#55635: `make-decoded-time' incorrectly sets DST to nil, it should be -1 (guess) Date: Tue, 31 May 2022 19:25:25 +0700 Message-ID: References: <940415ce-2e31-ae18-3e16-8fdc54504a67@gmail.com> <87o7zkbif3.fsf@gnus.org> <96e9d729-2e23-5637-3136-ac29e26aa287@cs.ucla.edu> <87r14f8dhw.fsf@gnus.org> <87zgj23pn9.fsf@gnus.org> <0e506652-fb7d-5707-8247-7747ff1e53b0@gmail.com> <83o7zhlht0.fsf@gnu.org> <87sfos1o3o.fsf@gnus.org> <6ce0d14a-017c-2b28-d924-fb461396c547@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37560"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: Eli Zaretskii , 55635-done@debbugs.gnu.org To: Paul Eggert , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 31 14:38:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nw18X-0009cE-4H for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 31 May 2022 14:38:13 +0200 Original-Received: from localhost ([::1]:55870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nw18V-0005qs-UF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 31 May 2022 08:38:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41446) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nw0wk-0006LQ-Oe for bug-gnu-emacs@gnu.org; Tue, 31 May 2022 08:26:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53042) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nw0wk-0005ua-DR for bug-gnu-emacs@gnu.org; Tue, 31 May 2022 08:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nw0wk-00068r-8S for bug-gnu-emacs@gnu.org; Tue, 31 May 2022 08:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Maxim Nikulin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 31 May 2022 12:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55635 X-GNU-PR-Package: emacs Original-Received: via spool by 55635-done@debbugs.gnu.org id=D55635.165399994223566 (code D ref 55635); Tue, 31 May 2022 12:26:02 +0000 Original-Received: (at 55635-done) by debbugs.gnu.org; 31 May 2022 12:25:42 +0000 Original-Received: from localhost ([127.0.0.1]:46939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nw0wP-000680-B7 for submit@debbugs.gnu.org; Tue, 31 May 2022 08:25:41 -0400 Original-Received: from mail-lj1-f172.google.com ([209.85.208.172]:45962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nw0wN-00067l-JA for 55635-done@debbugs.gnu.org; Tue, 31 May 2022 08:25:40 -0400 Original-Received: by mail-lj1-f172.google.com with SMTP id v9so14448022lja.12 for <55635-done@debbugs.gnu.org>; Tue, 31 May 2022 05:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:in-reply-to :content-transfer-encoding; bh=rnaosGgld+frQ5hiULFkCNSmMSN+xIVjyNv7fk/4yfw=; b=E4+PoAnp3dI5luv/u/pFKoMpPxt8sPWUIldPL8N9iaj7xhncWRxEYD/16Yiinh7Hkl 26G6nCvZJpYxmiv2RcolqppYq1zJnNrks6WveM9MSGYPS4tOUuLO0IDvRgug6It9UMVN yNycC5IoErN9G5JOtfAXmLVpd6fX2ocXcsIfkrRdfL1ARb5YEPhpVxhoLmRbvSnepg5m ff7H1cbfy2pUIoldaeB2e82sBWP9Zonrs3k1DlFvSZZSg7BFaRbmrxBBM/Tyg33A2vWG WyRvlRTvfD1Ccot5xbLbqADmUMiO0pj3DvdUh8Xz1AJpwjtG7aEGWFDzf6U29NqmKkbo NmVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:in-reply-to :content-transfer-encoding; bh=rnaosGgld+frQ5hiULFkCNSmMSN+xIVjyNv7fk/4yfw=; b=40ffZ8R7GFLugcnidEQ9OhakeUgPZLJjudFlVTBNRaoZbsSM8dXg+IjlhhbypmAASG 4pmvRhWTJH1JSzcgzB2yPAZr//ggGrbhEqFmNlkSgXc34T5cv0KHaB351eOqs2Kx7DSR GgtdetuW7XImccYyTafe1Gjhsm7yCdk4GqcrN+7t+qKwsLnZDLOZDmt6IUx8sQsNvNuP KstrSgUwbjOXzd5QoBxAo3sGxSG8SXI7iTjOb6xjaMJ8BjJj6OjlYNZbwRxrB8Rhd8X3 TTDX7r/jB9bg49NCVgZgjmFpqODZTpa77LrlE3CeqKxts096zp+edmQvw4lEMhEB7+5c x/Sw== X-Gm-Message-State: AOAM533AJ87Zy25SFViV8TG9fJntBVlWJg+TbPPPYxDT2eQgS2NW7ryZ Jvro7wfWQptBj08SGH6Ja+k= X-Google-Smtp-Source: ABdhPJwRzOgs20ZfMcKkiehUXKOoECCPb1eSIsxvt8qh6x+EblpXRqwwhtafc9vJZRLA2xoz5yauUA== X-Received: by 2002:a2e:a4c7:0:b0:255:4dac:fe4c with SMTP id p7-20020a2ea4c7000000b002554dacfe4cmr7184984ljm.353.1653999933437; Tue, 31 May 2022 05:25:33 -0700 (PDT) Original-Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id o16-20020ac24c50000000b0047255d2119bsm2932309lfk.202.2022.05.31.05.25.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 May 2022 05:25:32 -0700 (PDT) X-Google-Original-From: Maxim Nikulin Content-Language: en-US In-Reply-To: <6ce0d14a-017c-2b28-d924-fb461396c547@cs.ucla.edu> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:233432 Archived-At: On 30/05/2022 05:04, Paul Eggert wrote: > diff --git a/lisp/simple.el b/lisp/simple.el > index a254ee2251..d6b7045432 100644 > --- a/lisp/simple.el > +++ b/lisp/simple.el > @@ -10519,6 +10519,14 @@ capitalize-dwim > the number of seconds east of Greenwich.") > ) > > +;; Document that decoded-time-dst is problematic on 6-element lists. > +;; It should return -1 indicating unknown DST, but currently returns > +;; nil indicating standard time. > +(put 'decoded-time-dst 'function-documentation > + (append (get 'decoded-time-dst 'function-documentation) > + "As a special case, `decoded-time-dst' returns an unspecified > +value when given a list too short to have a dst element.")) > + Paul, thank you for your efforts to fix the issues. I have never used `cl-defstruct' before (and frankly speaking I am rather confused that the `decoded-time' struct and its constructor `make-decoded-time' are defined in different files and even directories are not the same), so my question may be naïve. Why did not you just add this new sentence to the :documentation property of the DST slot a bit above? By the way, after updating of `make-decoded-time', default value for DST should be updated in `cl-defstruct' as well, otherwise (describe-symbol 'decoded-time) reports that the default is nil. It may be reasonable to cross-link `decoded-time' and `make-decoded-time' in docstrings. Concerning timestamp vs. interval, first of all, I do not request immediate changes. I raised the question to make developers aware that the problem exist and it should be taken into account during further modifications or implementation of new features. Lars Ingebrigtsen, Sun, 29 May 2022 15:10:19 +0200. > If somebody wants to do > interval calculations and passes in a DST to make-decoded-time, that's a > classic "well, don't do that" situation. DST slot with -1 (default) value is rather confusing for intervals but it safer for timestamps. Certainly it possible to do anything with bytes in memory, but direction of programming languages and libraries development is to allow users to clearly express intentions code and to add some measures that prevents bugs. That is why I mentioned tagged structure for interval type to distinguish it from timestamps. Eli Zaretskii, Sat, 28 May 2022 19:53:47 +0300. >> From: Maxim Nikulin Date: Sat, 28 May 2022 23:31:43 +0700 >> >> I think, it is confusing that `make-decoded-time' is used to create >> timestamps *and* time intervals. They are different types, for example >> sum of intervals is meaningful (despite may be ambiguous) while there is >> no point to add timestamps. > > But this situation already exists with time units anyway. You can add > an hour to some other time, but there's also a valid time stamp that > expresses 1 hour past the epoch UTC, and their values are exactly > identical. Certainly timestamps are actually intervals with various reference points. Encoded time is counted from 1970, decoded time from 0 a.d., so trying to add the same timestamps you will get result depending on their representation. Decoded time in some cases is more convenient since 1 day may be not the same as 24 hours, not to mention varying duration of 1 month. The problem is that `decoded-time' time have field that are alien for intervals (timezone). Using the same constructor for both types makes code more obscure, it is impossible to enforce particular type of function argument to catch a programming error. It is possible to use the same type for timestamps and intervals further, I am trying to dispute that it is the best design choice.