RS-22971: Export a native date axis when category labels are dates

[chschan]

What & why

R side of the PowerPoint date axis export feature. When a chart's category labels are dates, Q can now export a native PowerPoint date axis (c:dateAx) instead of text categories — but only if it receives the underlying dates, because R always renders category labels as strings.

This change makes flipChart:

1. Declare the date axis — getPPTSettings sets ChartSettings$PrimaryAxis$AxisType = "Date" (+ a date NumberFormat) when the category labels are dates, for non-pie/non-scatter charts.
2. Supply the underlying dates — attaches a category.dates attribute (numeric date serials) plus category.date.format to ChartData, which Q reads to build the numeric numRef/dateAx.

How it works

• Capture happens in addCategoryDateAxisAttributes, called on the final prepared data just before PrepareData returns — so it covers every input path (table row labels, raw date variables, pasted) uniformly, and nothing downstream can strip the attribute.
• Handles the common "Automatic" date format (auto-detects the parse, leaves display labels unchanged) as well as explicit US/International (which also reformats the display labels, as before). "No date" opts out.

Tests

• New test-chartsettings-dateaxis.R: asserts ChartSettings$PrimaryAxis$AxisType == "Date" and the date serials on ChartData for Column/Area/Line/Bar, end-to-end through PrepareData → CChart, for both date-rownamed tables and raw Date variables; plus negatives (no date attr, Pie, non-date labels).
• All AI-generated and reviewed; verified passing locally with testthat (R 4.5.1), no regressions in test-preparedata.R / test-chartsettings.R.

Companion PR

Displayr/q#26940 (the C# side that consumes category.dates and emits the c:dateAx). This PR now checks the QFileFormat so it can be merged at any time, but the C# change is required for the exporting to fix.

[JustinCCYap]

The AxisType = "Date" block needs the same Q-version gate as LabelsRotation — as written, merging this before the q PR is deployed breaks PowerPoint export of date-labelled charts on current Q.

The consuming path in q parses ChartSettings enums via Enum.Parse, which throws on unknown names (RexpToObject.GetEnum in RInternals: Invalid string for 'AxisType' enum: Date), and PptChartSettingsAndLabels.LoadRObjectSettings rethrows that as a UserException — so the whole export fails. Any Q that predates Displayr/q#26940 (i.e. all of production today) will error out exporting any chart whose category labels are dates, where it previously exported them fine as text categories. The PR description's "can be merged at any time" currently only holds for LabelsRotation.

Suggested fix in getPPTSettings:

1. Wrap the res$PrimaryAxis$AxisType <- "Date" / NumberFormat assignments in the same q.file.format.version check used for LabelsRotation.
2. Use >= 28.08 rather than > 28.06 for both gates: internal Q builds report master + 0.01 (28.07) and may predate the change — that's why q bumps the format version by 0.02.

(category.dates itself doesn't need gating — old Q ignores unknown attributes via TryGetAttr. Only the ChartSettings declaration goes through the throwing reflection path.)

[JustinCCYap]

Unmapped strftime tokens survive substitution and end up verbatim in the PPT format code. The predefined "Date/Time" dropdown formats are all covered by the token table, but ChartNumberFormat returns a user-typed custom format verbatim, and d3-time-format accepts tokens outside the mapped set (%e, %-d, %q, %j, %L, %Z, ...). Any of these passes the grepl("%[A-Za-z]") date detection but is left untouched by the gsub loop.

The consequence isn't just a literal rendering: in an Excel/PowerPoint number format, each % multiplies the displayed value by 100, so a leftover token corrupts the axis labels (OADate serial x 100) rather than degrading gracefully.

Cheap guard — treat any incomplete conversion as "not a date format" so the caller falls back to category.date.format:

    for (token in names(tokens))
        result <- gsub(token, tokens[[token]], result, fixed = TRUE)
    if (grepl("%", result, fixed = TRUE))
        return(NULL)
    result

Worth a test case alongside the existing convertToPPTDateFormat ones (e.g. expect_null(convertToPPTDateFormat("%e %b %Y"))).

[chschan]

Fixed in the latest push. After the substitution loop, any remaining % (unmapped token or user-typed custom format) now returns NULL, so the caller falls back to category.date.format instead of emitting a corrupt x100 axis. Added expect_null cases for %e %b %Y, %-d %b %Y, and %j.

[chschan]

The AxisType = "Date" block needs the same Q-version gate as LabelsRotation

Good catch, both applied in 3836edd:

1. AxisType = "Date" / NumberFormat are now gated on QFileFormatVersion exactly like LabelsRotation (shared q.can.parse.date.axis flag), so older Q never receives the unparseable enum value and date-labelled charts keep exporting as text categories there. category.dates stays ungated as you noted (old Q ignores unknown ChartData attributes).
2. Both gates now use >= 28.08 instead of > 28.06, so internal 28.07 builds that predate the change are excluded.

Added a test asserting the date-axis ChartSettings are withheld at 28.06 / 28.07 / no-version, and the positive date-axis tests now set QFileFormatVersion = 28.08.

[JustinCCYap]

as.integer() truncates fractional angles for no reason now — the companion q PR changed LabelsRotation from int to double precisely so it accepts reals, and its test parses both an R integer and an R real vector. Suggest as.numeric(args$categories.tick.angle) so a fractional tick angle survives the round trip.

[chschan]

Done — now uses as.numeric(args$categories.tick.angle), so a fractional angle survives the round trip. I also fixed the q side: it was pre-rounding to a whole degree before ToTextBody (which took an int). Since PowerPoint stores text rotation in 60,000ths of a degree, I widened ToTextBody's rotation to double and round only at that conversion, so a fractional angle (e.g. 45.5°) now survives all the way to the exported axis. Added a test (45.5 on the flipChart side, and a q test asserting rot = 45.5 × 60000).

[JustinCCYap]

Has the rotation direction been checked manually in PowerPoint? Plotly's positive tickangle and PPT's positive body rotation are both clockwise, so the pass-through looks right on paper — but q's own convention for vertical category labels is -90 (bottom-to-top; see PptChartSettings.cs / PptChartSettingsAndLabels.cs), so an exported 90 would read top-to-bottom where q-native charts read bottom-to-top. Worth one visual comparison of a widget with categories.tick.angle = 90 against its export to confirm the labels match.

[chschan]

Yes, checked manually

[JustinCCYap]

LGTM, just a minor comment about as.integer()