[
https://issues.apache.org/jira/browse/GROOVY-12357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18113665#comment-18113665
]
ASF GitHub Bot commented on GROOVY-12357:
-----------------------------------------
paulk-asert merged PR #2919:
URL: https://github.com/apache/groovy/pull/2919
> 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
> Priority: Major
>
> 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)
