From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Represent NTP's origin time Date: Thu, 15 Apr 2021 08:40:22 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17984"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Ulrich Mueller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 15 14:44:31 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lX1MF-0004bV-KV for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Apr 2021 14:44:31 +0200 Original-Received: from localhost ([::1]:33710 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lX1ME-0001Kn-I8 for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Apr 2021 08:44:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49610) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lX1IT-0006cc-0E for emacs-devel@gnu.org; Thu, 15 Apr 2021 08:40:37 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46973) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lX1IO-0004wy-6U for emacs-devel@gnu.org; Thu, 15 Apr 2021 08:40:36 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BF2D48081F; Thu, 15 Apr 2021 08:40:29 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 693348066D; Thu, 15 Apr 2021 08:40:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618490423; bh=VMCVTE5o9DPxEITM5oDUEGq9XORawllHqOwgn7vWvQY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=MNyh8Mr5bx7YfqxB9F90V6WAQiQLrgsPBjXlyBoQQbNttp8L2sHH8+guGjHsXhpcY uqZ2hJIs1J8teyex3m/leZwXNmVtEbpa5s1/UJQadykxHgH10Qib0ToHJ5hZJushAH XUbORFe8vnNceVBe+8XAUC0LxFhTuAKIUbcLjYDPGwskqMybeYNt0VHPXeFGiPd3ti YeqyZESz5eFwTiChQ3nYtZQa7YwVNkftyhpvEplBIk1P2zmG9dNIlUUQm/YPKXGGAw cPmkmI09p1J1T2DR+1zHGBsAcy2mmLe5ftDfRjHAq8thJxmXQ1VbeldR1MJWc6Io43 Y/MF8Ytz5oBYQ== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EBADD1201AF; Thu, 15 Apr 2021 08:40:22 -0400 (EDT) In-Reply-To: (Ulrich Mueller's message of "Thu, 15 Apr 2021 10:27:27 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268087 Archived-At: >> NTP represents time stamps by counting seconds from January 1 1900, but >> my Emacs doesn't seem to be able to represent this: > >> (encode-time (parse-time-string "1902-01-01T00:00-00:00")) >> => (-32745 59520) >> (encode-time (parse-time-string "1900-01-01T00:00-00:00")) >> => (error "Specified time is not representable") > >> Do we have some "standard" workaround? > > Overflow in the underlying mktime(3) or mktime_z(3)? Are there still > systems around where time_t has only 32 bits? AFAIK all GNU/Linux i386 installations do. Nowadays amd64 is more common, but most of my machines are still running an i386 image and I'm pretty sure I'm not the only one. Also all armhf GNU/Linux systems do, and machines for which this is the main/sole option are still being produced. So, getting back to the question: Do we have some "standard" workaround? I don't actually need to represent times from the early 20th century, but I need to compute NTP timestamps. I can come up with my own workaround (e.g. hardcoding as a "magic constant" the number of seconds between NTP's origin time and some arbitrary other origin time of my choosing which 32bit systems can represent), but I was hoping we already have something like that somewhere. Stefan