From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures Date: Thu, 01 Aug 2019 13:21:21 +0200 Message-ID: <877e7xnnbi.fsf@mouse.gnus.org> References: <20190729122247.28663.99759@vcs0.savannah.gnu.org> <20190729122257.00600207F5@vcs0.savannah.gnu.org> <87imriymhk.fsf@tcd.ie> <87mugund5x.fsf@mouse.gnus.org> <02976867-d320-51aa-c4cb-864831a5ac35@cs.ucla.edu> <87r265z0r0.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="55596"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Paul Eggert , emacs-devel@gnu.org To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 01 13:21:49 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ht99Y-000EL0-Pf for ged-emacs-devel@m.gmane.org; Thu, 01 Aug 2019 13:21:48 +0200 Original-Received: from localhost ([::1]:54710 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1ht99X-0005Gs-KL for ged-emacs-devel@m.gmane.org; Thu, 01 Aug 2019 07:21:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59604) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1ht99F-0005FJ-EO for emacs-devel@gnu.org; Thu, 01 Aug 2019 07:21:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ht99E-0005cc-CN for emacs-devel@gnu.org; Thu, 01 Aug 2019 07:21:29 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:60788) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ht99E-0005cI-5y for emacs-devel@gnu.org; Thu, 01 Aug 2019 07:21:28 -0400 Original-Received: from 77.18.62.220.tmi.telenormobil.no ([77.18.62.220] helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ht998-0006IJ-B3; Thu, 01 Aug 2019 13:21:24 +0200 In-Reply-To: <87r265z0r0.fsf@tcd.ie> (Basil L. Contovounesios's message of "Thu, 01 Aug 2019 12:35:47 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.231.51 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239089 Archived-At: "Basil L. Contovounesios" writes: > While having a second look at this I noticed timezone-leap-year-p is > identical to date-leap-year-p. Should the former become an obsolete > alias of the latter? Ah, basically all these functions in the timezone package have the functions that I added to time-date while writing iso8601. ;; Partly copied from Calendar program by Edward M. Reingold. ;; Thanks a lot. (defun timezone-last-day-of-month (month year) [...] (defun timezone-leap-year-p (year) [...] (defun timezone-day-number (month day year) I don't think "timezone" is a logical naming for these, so I think they should be made into obsolete aliases for the time-date functions. There's also (defun timezone-absolute-from-gregorian (month day year) And digging even further back, there's `timezone-parse-date', which basically tries to parse anything even remotely time-like in a string (and has exactly one in-tree user, nnrss.el). Hm... Well, it pretty much looks like almost all the functions in that file have no or very few in-tree usages, and there are more modern counterparts to all of them, I think. I'm guessing that we've reached this state of affairs because newer time/date handling functions have been added over the years, and that the "timezone" prefix isn't an obvious place to look for these things, so any usages over the years have gone away. I think making (almost) all of them obsolete and adjusting the callers (if any) is probably the way to go. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no