1
$\begingroup$

Bug introduced in 13.0 or earlier and persisting through 13.2.0 or later.


It seems IntervalUnion may lead to unexpected results when applied to DateInterval with a granularity other than "Instant".

For instance, for

dtInt = DateInterval[{{2020, 5, 3}, {2021, 9, 6}}]

enter image description here,

IntervalUnion[dtInt]=== dtInt

is supposed to give True but instead gives False as IntervalUnion[dtInt] evaluates into

enter image description here.

Note the one day difference for the ending timestamps between dtInt and IntervalUnion[dtInt].

I'm wondering if this should be considered as a bug or something I'm missing?

$\endgroup$
3
  • $\begingroup$ "IntervalUnion" takes "Interval" as arguments, not "DateInterval" $\endgroup$ Jan 18, 2022 at 19:37
  • 1
    $\begingroup$ @DanielHuber No; please see this: wolfram.com/xid/0i1o1d4ti-dwtidm $\endgroup$
    – sunt05
    Jan 18, 2022 at 19:43
  • $\begingroup$ this bug persists in 13.0.1. $\endgroup$
    – sunt05
    Feb 17, 2022 at 20:44

1 Answer 1

3
$\begingroup$

After looking into the implementation of DateInterval, it seems this is indeed a bug in the internal conversion between numerical representation of a DateObject and its standard form.

When converting the ending timestamp of a numerical interval to a DateObject, the granularity should be deducted for a correct offset:

ResourceFunction[
  "PrintDefinitions"][DateAndTime`NumericValueListToDateInterval]

enter image description here

While it seems granularity is correctly accounted for in the following conversion:

ResourceFunction[
  "PrintDefinitions"][DateAndTime`DateIntervalToNumericValueList]

enter image description here

then click into dateToNumericValue:

enter image description here

A bug report has been filed to WRI [CASE:4897342].

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.