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

Previous Next

Full log

View this message in rfc822 format

From: Richard Lawrence <rwl <at> recursewithless.net>
To: 74869 <at> debbugs.gnu.org
Subject: bug#74869: [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 --------------------

Previous Next

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