unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: master 6cfda69 1/2: Add support for dealing with decoded time structures
       [not found] ` <20190729122257.00600207F5@vcs0.savannah.gnu.org>
@ 2019-07-30  5:19   ` Glenn Morris
  2019-07-30 10:01     ` Lars Ingebrigtsen
  2019-07-31 20:31   ` [Emacs-diffs] " Basil L. Contovounesios
  1 sibling, 1 reply; 7+ messages in thread
From: Glenn Morris @ 2019-07-30  5:19 UTC (permalink / raw)
  To: emacs-devel; +Cc: Lars Ingebrigtsen


> branch: master
> commit 6cfda69d72cb9debefc48d0d95e341d389e7303a

test-ordinal fails, ref
https://hydra.nixos.org/build/97306625

Same failure on RHEL7.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 6cfda69 1/2: Add support for dealing with decoded time structures
  2019-07-30  5:19   ` master 6cfda69 1/2: Add support for dealing with decoded time structures Glenn Morris
@ 2019-07-30 10:01     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 7+ messages in thread
From: Lars Ingebrigtsen @ 2019-07-30 10:01 UTC (permalink / raw)
  To: Glenn Morris; +Cc: emacs-devel

Glenn Morris <rgm@gnu.org> writes:

>> branch: master
>> commit 6cfda69d72cb9debefc48d0d95e341d389e7303a
>
> test-ordinal fails, ref
> https://hydra.nixos.org/build/97306625
>
> Same failure on RHEL7.

Thanks; I had forgotten to adjust a series of tests after adjusting the
output of one of the functions.  Should be fixed now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures
       [not found] ` <20190729122257.00600207F5@vcs0.savannah.gnu.org>
  2019-07-30  5:19   ` master 6cfda69 1/2: Add support for dealing with decoded time structures Glenn Morris
@ 2019-07-31 20:31   ` Basil L. Contovounesios
  2019-07-31 20:48     ` Lars Ingebrigtsen
  1 sibling, 1 reply; 7+ messages in thread
From: Basil L. Contovounesios @ 2019-07-31 20:31 UTC (permalink / raw)
  To: emacs-devel; +Cc: Lars Ingebrigtsen

larsi@gnus.org (Lars Ingebrigtsen) writes:

> branch: master
> commit 6cfda69d72cb9debefc48d0d95e341d389e7303a
> Author: Lars Ingebrigtsen <larsi@gnus.org>
> Commit: Lars Ingebrigtsen <larsi@gnus.org>
>
>     Add support for dealing with decoded time structures
>     

[...]

> --- a/lisp/calendar/time-date.el
> +++ b/lisp/calendar/time-date.el
> @@ -36,6 +36,9 @@
>  
>  ;;; Code:
>  
> +(require 'cl-lib)
> +(require 'subr-x)

The latter can be wrapped in eval-when-compile, right?

> +(defun date-days-in-month (year month)
> +  "The number of days in MONTH in YEAR."
> +  (if (= month 2)
> +      (if (date-leap-year-p year)
> +          29
> +        28)
> +    (if (memq month '(1 3 5 7 8 10 12))
> +        31
> +      30)))

Doesn't this already exist as the Gregorian calendar-last-day-of-month
in calendar.el?

[...]

Out of curiosity, where does the jurisdiction of time-date.el end and
calendar.el begin?  Is the former focussed more on internal timestamp
handling, and the latter on the more user-facing (M D Y) format and the
Calendar application?

Thanks,

-- 
Basil



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures
  2019-07-31 20:31   ` [Emacs-diffs] " Basil L. Contovounesios
@ 2019-07-31 20:48     ` Lars Ingebrigtsen
  2019-08-01  2:38       ` Paul Eggert
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2019-07-31 20:48 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: emacs-devel

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>> +(require 'cl-lib)
>> +(require 'subr-x)
>
> The latter can be wrapped in eval-when-compile, right?

Probably...  but I think, these days, the likelihood of subr-x not being
loaded by something in your Emacs is pretty slim, so I'm not sure it's
worth wrapping those in the case where we only use macros from it.

>> +(defun date-days-in-month (year month)
>> +  "The number of days in MONTH in YEAR."
>> +  (if (= month 2)
>> +      (if (date-leap-year-p year)
>> +          29
>> +        28)
>> +    (if (memq month '(1 3 5 7 8 10 12))
>> +        31
>> +      30)))
>
> Doesn't this already exist as the Gregorian calendar-last-day-of-month
> in calendar.el?

Yes, apparently.  (I didn't know about it.)

> Out of curiosity, where does the jurisdiction of time-date.el end and
> calendar.el begin?  Is the former focussed more on internal timestamp
> handling, and the latter on the more user-facing (M D Y) format and the
> Calendar application?

I assumed that it's all about the Calendar application.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures
  2019-07-31 20:48     ` Lars Ingebrigtsen
@ 2019-08-01  2:38       ` Paul Eggert
  2019-08-01  9:35         ` Basil L. Contovounesios
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2019-08-01  2:38 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Basil L. Contovounesios; +Cc: emacs-devel

>>> +(defun date-days-in-month (year month)
>>> +  "The number of days in MONTH in YEAR."
>>> +  (if (= month 2)
>>> +      (if (date-leap-year-p year)
>>> +          29
>>> +        28)
>>> +    (if (memq month '(1 3 5 7 8 10 12))
>>> +        31
>>> +      30)))
>>
>> Doesn't this already exist as the Gregorian calendar-last-day-of-month
>> in calendar.el?
> 
> Yes, apparently.  (I didn't know about it.)

The two functions are not equivalent, as date-days-in-month uses astronomical 
year numbering, whereas calendar-last-day-of-month uses traditional year 
numbering, with no year zero.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures
  2019-08-01  2:38       ` Paul Eggert
@ 2019-08-01  9:35         ` Basil L. Contovounesios
  2019-08-01 11:21           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Basil L. Contovounesios @ 2019-08-01  9:35 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Lars Ingebrigtsen, emacs-devel

Paul Eggert <eggert@cs.ucla.edu> writes:

> The two functions are not equivalent, as date-days-in-month uses astronomical
> year numbering, whereas calendar-last-day-of-month uses traditional year
> numbering, with no year zero.

Okay, thanks for pointing that out (though calendar-leap-year-p is
equivalent to date-leap-year-p for zero and positive years).

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?

Thanks,

-- 
Basil



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures
  2019-08-01  9:35         ` Basil L. Contovounesios
@ 2019-08-01 11:21           ` Lars Ingebrigtsen
  0 siblings, 0 replies; 7+ messages in thread
From: Lars Ingebrigtsen @ 2019-08-01 11:21 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: Paul Eggert, emacs-devel

"Basil L. Contovounesios" <contovob@tcd.ie> 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



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-08-01 11:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20190729122247.28663.99759@vcs0.savannah.gnu.org>
     [not found] ` <20190729122257.00600207F5@vcs0.savannah.gnu.org>
2019-07-30  5:19   ` master 6cfda69 1/2: Add support for dealing with decoded time structures Glenn Morris
2019-07-30 10:01     ` Lars Ingebrigtsen
2019-07-31 20:31   ` [Emacs-diffs] " Basil L. Contovounesios
2019-07-31 20:48     ` Lars Ingebrigtsen
2019-08-01  2:38       ` Paul Eggert
2019-08-01  9:35         ` Basil L. Contovounesios
2019-08-01 11:21           ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).