From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id GJhLBHcfyGPyfwEAbAwnHQ (envelope-from ) for ; Wed, 18 Jan 2023 17:33:59 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id WF5FBHcfyGNJSQEA9RJhRA (envelope-from ) for ; Wed, 18 Jan 2023 17:33:59 +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 CE5D33E33F for ; Wed, 18 Jan 2023 17:33:58 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIBMb-0003fO-Jj; Wed, 18 Jan 2023 11:32:37 -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 1pIBMN-0003c6-AL for emacs-orgmode@gnu.org; Wed, 18 Jan 2023 11:32:32 -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 1pIBMK-0007V6-QE for emacs-orgmode@gnu.org; Wed, 18 Jan 2023 11:32:22 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pIBMF-0002vz-Qv for emacs-orgmode@gnu.org; Wed, 18 Jan 2023 17:32:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: Observation of hysteresis in a GNU libc time conversion function Date: Wed, 18 Jan 2023 23:32:08 +0700 Message-ID: References: <871qns88xf.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: <871qns88xf.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.249, NICE_REPLY_A=-0.089, 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674059638; 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=OybWSd/HUapCKFcpJHwqiI5KjzgNUml3YRCY7QpIOZw=; b=rZf7+oqb7VqOpWl4xh0WzZaORV1aoItdOjr+35Q4vHF9B9xk25Rw3Dm/DhKthmVgMXW0bC d2mLt9v/NKJBEbsr64mz/YmvaOZ9wsI95zqx/fU5xYXpF7vRduOgv+hoPPTuX6y7o6GeKk WrVZFqqtHhS/JdELyd7Dikt0tSsgN3peexN3pk9KQIpwuArznvVqK+qxG1t2VxYNHzI2iZ Eg5SK5CEeOklOTsIH+2Nbeyp8dQ00XSopD9GNg02UJQNEasVQq81HYU/bSHcUbGlaJ0vTP iINTkOUjdL6znSdIAlu2FX6I2KOiidWs8TV+1RCHKQm7p2Vevyv74+9jq6Hu+w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1674059638; a=rsa-sha256; cv=none; b=hkdurkOmqcvLcPDUEet/uDynT9/rWBuIl6h+5LHryl/zrpSbf7PHwfTlWGWLev00UjG+Hz IOV10OxAWqUNsuqc7BQbxel1pBJMaZH98ugKvmYIAHNWvrc1rK8eEgbZX2UjOWzGmkViCq 1lhEtYJe3e4+jDNmSKu9ZQCIVN4w4M8QUkN6VPBzofIuq376/HwWwYEh5fI9EBWrE+G1Qf RdevsmwyM3CTff8KHMGO9AE4xCt43U8v9/SO+4W2Otm2vVuMvgdG1C/n/wfu1Kd3eX/Y1D YAdOffedAGEEjRDujs0gpmS89iUAKoskCzhTR2iG29yCw0rHBupR1w3oJS0YuQ== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 4.07 X-Spam-Score: 4.07 X-Migadu-Queue-Id: CE5D33E33F Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" 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-TUID: fxjwP9R1V295 On 18/01/2023 16:54, Ihor Radchenko wrote: > Max Nikulin writes: > >> (dt '(-90 -60 -31 -30 -29 -15 0 15 29 30 31 60 90)) > > This is problematic. You are putting MINUTES out of normal range. Actually after some experiments and surprising results I figured out what really happens. I modified your example to get the value that you was likely expecting: (let* ((tz "Europe/Berlin") (t1 (encode-time `(0 1 3 29 10 2023 nil -1 ,tz))) ;; !!! Try to comment out the line below (_ (encode-time `(0 59 1 29 10 2023 nil -1 ,tz))) (t2 (encode-time `(0 59 2 29 10 2023 nil -1 ,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) No negative minutes were involved. I decided that hysteresis example is more funny. Frankly speaking, I just forgot that I may use (make-decoded-time :minute -40) and `decoded-time-add' since I was not limited by Emacs-26 support. `encode-time' docstring for Emacs-26 has the following statement: > Out-of-range values for SECOND, MINUTE, HOUR, DAY, or MONTH are allowed; > for example, a DAY of 0 means the day preceding the given month. So I do not think it affects anything. I decided to ask GNU libc developers https://inbox.sourceware.org/libc-alpha/tq93sc$p3$1@ciao.gmane.io/T/#u "mktime result may depend on previous calls" > Looking at > https://codecogs.com/library/computing/c/time.h/ctime.php?alias=mktime, > out-of-range minutes are not documented. Looks like a compilation of unspecified sources. The following is similar to ctime(3) man page if structure members are outside their valid interval, they will be normalized (so that, for example, 40 October is changed into 9 November); My reading is that out of range values for other "members" are allowed as well. However it may be tricky. > Also, see > https://stackoverflow.com/questions/20104531/weird-mktime-logic-with-negative-seconds My expectation is that ±1 day (or month) should preserve local time hours (e.g. 11:00 CET -> 11:00 CEST) if such moment of time exists. ±24 hours, ±24*60 minutes, ±24*3600 seconds across DST change should cause appropriate shift of hours (e.g. 11:00 -> 12:00 is possible). Moreover "out of range" month day 0 is the only way to specify last month day to get Jan, 31 <- 1 month -> Feb, 28 (or 29) <- 1 month -> Mar, 31 arithmetic. However it is hardly implementation specific and GNU date(1) CLI utility, PostgreSQL, PHP timelib, JavaScript Date objects behave differently. I still do not think it affects my example though.