Paul King created GROOVY-12357:
----------------------------------
Summary: YamlSlurper and TomlSlurper: offer the date handling
JsonSlurper has (defaults unchanged)
Key: GROOVY-12357
URL: https://issues.apache.org/jira/browse/GROOVY-12357
Project: Groovy
Issue Type: Improvement
Reporter: Paul King
GROOVY-12352 gave {{JsonSlurper}} a choice of what a date-like string becomes —
{{STRING}}, {{UTIL_DATE}}, {{INSTANT}} or {{OFFSET_DATE_TIME}}, selected with
{{setDateHandling}}. The other slurpers have no equivalent: a timestamp in YAML
or TOML is always a {{String}} on the untyped path.
{code}
new YamlSlurper().parseText('when: 2026-09-05T10:00:00Z').when // String
new TomlSlurper().parseText('when = 2026-09-05T10:00:00Z').when // String
{code}
That is worth keeping as the default and offering a way out of, which is the
reverse of the JSON situation. {{JsonDateHandling}} exists because two of the
JSON parser types were already converting and callers needed to steer it, so
its default preserves that behaviour. Nothing in YAML or TOML has ever
converted, so the default here is {{STRING}} and nothing changes for an
existing caller. Parity of capability, with each format keeping its own status
quo.
h3. Proposal
{code:java}
public YamlSlurper setDateHandling(JsonDateHandling dateHandling)
public TomlSlurper setDateHandling(JsonDateHandling dateHandling)
{code}
defaulting to {{JsonDateHandling.STRING}}.
Reusing the JSON enum is deliberate rather than expedient. The untyped paths of
both slurpers already read by converting the document to JSON text and handing
it to a {{JsonSlurper}}, so the type in the signature names what actually
interprets the value. Verified end to end on that route:
{code}
when: 2026-09-05T10:00:00Z
-> {"when":"2026-09-05T10:00:00Z"}
-> OffsetDateTime 2026-09-05T10:00Z (INDEX_OVERLAY + OFFSET_DATE_TIME)
{code}
Implementation is correspondingly small: when the handling is not {{STRING}},
configure the internal slurper with a date-capable parser type and the
requested handling, and delegate.
h3. What this deliberately is not
* Not YAML {{!!timestamp}} semantics. The conversion applies the same lexical
rule JSON uses — a full ISO-8601 or JSON-date form converts, a bare date does
not — after the document has become JSON. Document it as JSON's rule, because
it is.
* Not the typed path, which has had its answer since GROOVY-12012: declare
{{java.time}} fields on the target class and {{parseAs}} binds them.
* Not {{CsvSlurper}}. CSV has no date syntax to recognise; a cell is text. It
can join later if wanted, but it is not part of this ticket.
h3. Sequencing
Additive, default-preserving, so it does not need to catch 6.0.0. The only
decision with an RC deadline is the one this ticket assumes: that
{{JsonDateHandling}}, shipping for the first time in 6.0.0, is the family-wide
type rather than a JSON-only one. If a format-neutral name is preferred
instead, that rename has to happen before the enum is released, not here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)