12.1p+: Bug with DateRangeItem and presetOptions

[Blama]

Hi Isomorphic,

trying your RelativeDateItem.presetOptions feature that you mentioned here I noticed a few bugs in this modified sample (v12.1p_2023-06-27, also v13.0p_2023-07-07):
In the DateRangeItem fromField has problem with all 'End x' selections, toField has problems with all 'Start x' selections. They either don't work at all or select off by one dates.
The same presetOptions work as expected in the RelativeDateItem below.

Best regards
Blama

isc.DynamicForm.create({
    ID: "form1",
    width: 620,
    colWidths: [190, "*"],
    fields: [{
            name: "static",
            showTitle: false,
            value: "DateRangeItem: fromField problem with all 'End x' selections, toField problems with all 'Start x' selections",
            width: 400,
            colSpan: 2,
            editorType: "StaticTextItem"
        },
        {
            name: "dri",
            title: "DateRangeItem (not OK)",
            width: 400,
            editorType: "DateRangeItem",
            allowRelativeDates: true,
            fromFieldProperties: {
                presetOptions: {
                    "-0Y[-0Y]": "Start of year",
                    "+0Y[-0Y]": "End of year",
                    "-0Q[-0Q]": "Start of quarter",
                    "+0Q[-0Q]": "End of quarter",
                    "-0M[-0M]": "Start of month",
                    "+0M[-0M]": "End of month"
                }
            },
            toFieldProperties: {
                presetOptions: {
                    "-0Y[-0Y]": "Start of year",
                    "+0Y[-0Y]": "End of year",
                    "-0Q[-0Q]": "Start of quarter",
                    "+0Q[-0Q]": "End of quarter",
                    "-0M[-0M]": "Start of month",
                    "+0M[-0M]": "End of month"
                }
            }
        },
        {
            name: "rdi",
            title: "RelativeDateItem (OK)",
            width: 400,
            editorType: "RelativeDateItem",
            presetOptions: {
                "-0Y[-0Y]": "Start of year",
                "+0Y[-0Y]": "End of year",
                "-0Q[-0Q]": "Start of quarter",
                "+0Q[-0Q]": "End of quarter",
                "-0M[-0M]": "Start of month",
                "+0M[-0M]": "End of month"
            }
        }
    ]
});

[Isomorphic]

Thanks for the report.

Firstly, for clarity, case matters in relative-date strings - lower-case is an amount, upper-case implies rounding to the boundary of that amount. For example, "+1d" is tomorrow, being 24 hours after now(), where "+1D" is the end of tomorrow, and "+1d[-0D]" or "+1D[-0D]" both produce the start of tomorrow, via the modifier (in []). You don't need a modifier in any of you example relative-strings, because they're all simple and already use upper-cased time-units.

With that said, the underlying issue here was that a DateRangeItem sets RelativeDateItem.rangePosition on its child RDIs, and that feature rounds from-dates to the start of their period, and to-dates to the end. So, if you choose Today for both From and To dates, the range is from the start to the end of Today. But that mechanism is only applicable to RelativeDateShortcuts, like $today, and not to RelativeDateStrings, where you can apply the rounding behavior yourself via a modifier.

We have a change in testing to correct the behavior and it should hit tomorrow's builds, dated July 11 and later.

[Blama]

Hi Isomorphic,

sorry, I don't fully understand your answer. Are you saying what one sees is correct and you only changed your tests to catch other edge cases?
Or did you chance the framework code? Because I'm still seeing what I described in v13.0p_2023-07-12 and v12.1p_2023-07-13.

Best regards
Blama

[Isomorphic]

Yes, sorry, there is indeed a bug that needs to be fixed - a fix was devised a few days ago but didn't hit the builds yet, due to priorities on other things. We'll get it finished in the next day or two and update here once it's in.