Re: master 6cfda69 1/2: Add support for dealing with decoded time structures

Re: master 6cfda69 1/2: Add support for dealing with decoded time structures

[Glenn Morris]

> branch: master
> commit 6cfda69d72cb9debefc48d0d95e341d389e7303a

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

Same failure on RHEL7.

Re: master 6cfda69 1/2: Add support for dealing with decoded time structures

[Lars Ingebrigtsen]

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

Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures

[Basil L. Contovounesios]

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

Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures

[Lars Ingebrigtsen]

"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

Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures

[Paul Eggert]

>>> +(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.

Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures

[Basil L. Contovounesios]

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

Re: [Emacs-diffs] master 6cfda69 1/2: Add support for dealing with decoded time structures

[Lars Ingebrigtsen]

"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