GNU bug report logs - #74869
[PATCH] Add predicates for decoded times and time deltas

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74869 in the body.
You can then email your comments to 74869 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Lawrence <rwl <at> recursewithless.net>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Add predicates for decoded times and time deltas
Date: Sat, 14 Dec 2024 17:11:41 +0100

[Message part 1 (text/plain, inline)]

Tags: patch

This is a rough draft of a patch to add two new predicates related to
decoded times: `decoded-time-p', which checks that a value is a decoded
time (as documented in `decode-time'), and
`decoded-time-delta-p', which checks that a value is a time delta (as
documented in `decoded-time-add').

Some questions:

1) Should these functions go in simple.el? I put them there because that
is where the structure definition for decoded-time is. (The definition
does not generate a predicate automatically because it uses :type but
not :named; see Info node `(cl)Structures'.) But at least
`decoded-time-delta-p' might be better off in time-date.el, which is
where `decoded-time-add' is defined.

2) Should `decoded-time-p' also check the weekday slot of decoded times?
See the FIXME comment in the middle of the function: `make-decoded-time'
neither sets this slot nor provides an argument to let the caller set
it. This is apparently intentional: there is a comment in the
definition of `make-decoded-time',

  ;; Do not set decoded-time-weekday or decoded-time-dst,
  ;; as encode-time can infer them well enough when unknown.

but if the slot is not meant to be set I don't understand why it's
there. It would be useful, for iCalendar purposes, to have the weekday
slot automatically calculated from the date values when a decoded time
is constructed. I'm not sure if this use was just not envisioned, or if
there was a more substantial reason not to do it in make-decoded-time.

Hopefully I got the commit message right this time, but please let me
know if that needs tweaking too...

Best,
Richard

[0001-Add-predicates-for-decoded-times-and-time-deltas.patch (text/patch, attachment)]

Message #8 received at 74869 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 74869 <at> debbugs.gnu.org
Cc: Richard Lawrence <rwl <at> recursewithless.net>
Subject: Fwd: [PATCH] Add predicates for decoded times and time deltas
Date: Sun, 29 Dec 2024 11:17:33 -0800

Argh, I now see that I cc'ed the wrong bug report. It should be bug 
74869, not 74689. Forwarding this two-day-old email to the correct bug 
report. Sorry about the duplication.


-------- Forwarded Message --------
Subject: Re: [PATCH] Add predicates for decoded times and time deltas
Date: Fri, 27 Dec 2024 16:44:32 -0800
From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Richard Lawrence <rwl <at> recursewithless.net>
CC: 74689 <at> debbugs.gnu.org

What's the use case for these proposed predicates? I'm finding it hard 
to review the patch without knowing what it's for.

Surely this should be in time-date.el rather than simple.el.

The implementation of decoded-time-p seems complicated and doesn't match 
what decode-time produces. Wouldn't it be simpler to call (ignore-errors 
(equal val (decode-time (encode-time val))))?

Message #11 received at 74869 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 74869 <at> debbugs.gnu.org
Cc: Richard Lawrence <rwl <at> recursewithless.net>
Subject: Fwd: [PATCH] Add predicates for decoded times and time deltas
Date: Sun, 29 Dec 2024 11:18:33 -0800

Forwarding another mis-addressed email of mine.


-------- Forwarded Message --------
Subject: Re: [PATCH] Add predicates for decoded times and time deltas
Date: Sat, 28 Dec 2024 09:26:23 -0800
From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Richard Lawrence <rwl <at> recursewithless.net>
CC: 74689 <at> debbugs.gnu.org

On 12/28/24 07:56, Richard Lawrence wrote:
> I need to use
> `calendar-extract-month' with a plain date value, but
> `decoded-time-month' with a date-time value. I need type predicates to
> do such dispatching.

Not necessarily; you can instead try each function in turn and use the 
first that works.

I have some qualms about saying that decoded times are a "type". Whether 
a decoded time is valid depends on the timezone: (0 30 2 10 3 2024 0 t 
-21600) is a valid decoded time in Phoenix but not in Denver, because 
clocks sprang forward over that time in Denver but not in Phoenix. When 
data interpretation gets that complicated, the Emacs notion of "type" is 
not always the best.

Message #16 received at 74869 <at> debbugs.gnu.org (full text, mbox):

From: Richard Lawrence <rwl <at> recursewithless.net>
To: 74869 <at> debbugs.gnu.org
Subject: Re: [PATCH] Add predicates for decoded times and time deltas
Date: Sun, 05 Jan 2025 09:45:10 +0100

I'm also forwarding a mis-addressed email back to the relevant bug list

-------------------- Start of forwarded message --------------------
From: Richard Lawrence <rwl <at> recursewithless.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: [PATCH] Add predicates for decoded times and time deltas
Date: Sun, 29 Dec 2024 09:05:03 +0100

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

> On 12/28/24 07:56, Richard Lawrence wrote:
>> I need to use
>> `calendar-extract-month' with a plain date value, but
>> `decoded-time-month' with a date-time value. I need type predicates to
>> do such dispatching.
>
> Not necessarily; you can instead try each function in turn and use the 
> first that works.

Well, in this case, they'll both "work" but can return incorrect values:
`calendar-extract-month' is just implemented as `car', so if I call it
on a decoded time, I'll get the seconds slot value rather than the month
slot value. Similarly, `decoded-time-second' will return the month if
called on a calendar date. 

If both calendar dates and decoded times were implemented as
records/cl-structs, rather than plain lists, then these accessor
functions could signal an error if passed a value of the wrong type. But
they aren't, and that doesn't seem likely to change anytime soon, so
having a predicate seems important.

> I have some qualms about saying that decoded times are a "type". Whether 
> a decoded time is valid depends on the timezone: (0 30 2 10 3 2024 0 t 
> -21600) is a valid decoded time in Phoenix but not in Denver, because 
> clocks sprang forward over that time in Denver but not in Phoenix. When 
> data interpretation gets that complicated, the Emacs notion of "type" is 
> not always the best.

I see. Would it help to change the name, or add some documentation, to
make it clear that the predicate doesn't (can't?) test for cases like
this? What about calling it something like `decoded-time-like-p' or
`maybe-decoded-time-p'? 

The iCalendar standard sets clear limits on the slot values, but these
aren't fine grained enough to rule out cases like the one you gave. All
it says is basically:

a date-time consists of a year, month, month-day, hour, minute, second,
  and (possibly) a UTC offset
a year is a four digit (positive) integer
a month is in the range 1-12
a month-day is in the range 1-28, 1-29, 1-30, or 1-31, depending on the
  month and year
an hour is in the range 0-23
a minute is in the range 0-59
a second is in the range 0-60 (60 represents a leap second)
a UTC offset is a sign together with an hour, minute, and second,
  where the second cannot be 60

So that's what the iCalendar code needs to check for. If it would be
better to keep this predicate in the iCalendar code, I can certainly do
that. I thought it would be more generally useful and should therefore
go with the existing code for decoded times, but maybe I was wrong about
that.

Best,
Richard
-------------------- End of forwarded message --------------------

Message #19 received at 74869 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 74869 <at> debbugs.gnu.org, Richard Lawrence <rwl <at> recursewithless.net>
Subject: Re: bug#74869: Fwd: [PATCH] Add predicates for decoded times and time
 deltas
Date: Tue, 11 Feb 2025 11:14:05 -0800

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

> Forwarding another mis-addressed email of mine.
>
>
> -------- Forwarded Message --------
> Subject: Re: [PATCH] Add predicates for decoded times and time deltas
> Date: Sat, 28 Dec 2024 09:26:23 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> To: Richard Lawrence <rwl <at> recursewithless.net>
> CC: 74689 <at> debbugs.gnu.org
>
> On 12/28/24 07:56, Richard Lawrence wrote:
>> I need to use
>> `calendar-extract-month' with a plain date value, but
>> `decoded-time-month' with a date-time value. I need type predicates to
>> do such dispatching.
>
> Not necessarily; you can instead try each function in turn and use the first
> that works.
>
> I have some qualms about saying that decoded times are a "type". Whether a
> decoded time is valid depends on the timezone: (0 30 2 10 3 2024 0 t -21600) is
> a valid decoded time in Phoenix but not in Denver, because clocks sprang forward
> over that time in Denver but not in Phoenix. When data interpretation gets that
> complicated, the Emacs notion of "type" is not always the best.

Does that mean to imply that this bug is a wontfix?

Message #22 received at 74869 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 74869 <at> debbugs.gnu.org, Richard Lawrence <rwl <at> recursewithless.net>
Subject: Re: bug#74869: Fwd: [PATCH] Add predicates for decoded times and time
 deltas
Date: Tue, 11 Feb 2025 16:44:21 -0800

On 2/11/25 11:14, Stefan Kangas wrote:

> Does that mean to imply that this bug is a wontfix?

Given rwl's December 29 message 
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74869#16> it sounds like 
it might be better to have something like an icalendar-decoded-time-p 
function, which follows the iCalendar standard as opposed to Emacs's 
more-idiosyncratic rules. So, not a wontfix; more a "let's keep this in 
iCalendar for now".

Message #25 received at 74869 <at> debbugs.gnu.org (full text, mbox):

From: Richard Lawrence <rwl <at> recursewithless.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Stefan Kangas <stefankangas <at> gmail.com>
Cc: 74869 <at> debbugs.gnu.org
Subject: Re: bug#74869: Fwd: [PATCH] Add predicates for decoded times and
 time deltas
Date: Wed, 12 Feb 2025 06:20:45 +0100

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

> On 2/11/25 11:14, Stefan Kangas wrote:
>
>> Does that mean to imply that this bug is a wontfix?
>
> Given rwl's December 29 message 
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74869#16> it sounds like 
> it might be better to have something like an icalendar-decoded-time-p 
> function, which follows the iCalendar standard as opposed to Emacs's 
> more-idiosyncratic rules. So, not a wontfix; more a "let's keep this in 
> iCalendar for now".

Yes, that's fine with me; so I guess this bug can be closed.

By the way, Paul, since you seem to be the (a?) local expert on
time-related stuff: I think I am getting close to having a working
implementation of iCalendar recurrence rules, which are needed to have
fully working semantics for iCalendar date-time values (because time
zone definitions use recurrence rules). But the code has been difficult
to write and I would really appreciate having an expert look over it
when it's ready...would you have any time for that in the nearish future?

Message #30 received at 74869-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Richard Lawrence <rwl <at> recursewithless.net>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 74869-done <at> debbugs.gnu.org
Subject: Re: bug#74869: Fwd: [PATCH] Add predicates for decoded times and time
 deltas
Date: Tue, 11 Feb 2025 21:51:43 -0800

Richard Lawrence <rwl <at> recursewithless.net> writes:

> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
>> On 2/11/25 11:14, Stefan Kangas wrote:
>>
>>> Does that mean to imply that this bug is a wontfix?
>>
>> Given rwl's December 29 message
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74869#16> it sounds like
>> it might be better to have something like an icalendar-decoded-time-p
>> function, which follows the iCalendar standard as opposed to Emacs's
>> more-idiosyncratic rules. So, not a wontfix; more a "let's keep this in
>> iCalendar for now".
>
> Yes, that's fine with me; so I guess this bug can be closed.

OK, so I'm doing that now.

Thanks for working improving our iCalendar support, that is greatly
appreciated.

Message #33 received at 74869 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Richard Lawrence <rwl <at> recursewithless.net>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: 74869 <at> debbugs.gnu.org
Subject: Re: bug#74869: Fwd: [PATCH] Add predicates for decoded times and time
 deltas
Date: Tue, 11 Feb 2025 22:28:51 -0800

On 2025-02-11 21:20, Richard Lawrence wrote:
> would you have any time for that in the nearish future?

Unfortunately I'm a little booked for something like a time code audit. 
If you have any questions though I could try to answer them.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.