[
https://issues.apache.org/jira/browse/TINKERPOP-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17913094#comment-17913094
]
Cole Greer commented on TINKERPOP-3125:
---------------------------------------
I wanted to highlight some additional considerations around this, the switch
from java.util.Date to OffsetDatetime in TinkerPop 4 has an unintended side
effect of switching the `asString()` outputs for dates to ISO 8601 format which
is roundtrip-able:
{noformat}
// TinkerPop 4.0.0-SNAPSHOT
gremlin> g.inject("2025-02-14").asDate().asString()
==>2025-02-14T00:00Z
gremlin> g.inject("2025-02-14").asDate().asString().asDate()
==>2025-02-14T00:00Z
gremlin> g.inject("2025-02-14T00:00Z").asDate()
==>2025-02-14T00:00Z
{noformat}
Additionally the time portion of the datestring can easily be truncated with
substring() if users only want the date portion. I would argue that the new TP4
format is generally more useful and a preferable default compared to the
existing 3.7 format.
It seems clear that 3.7 would still benefit from some sort of extension to
asString or format to improve the behaviour there, although there should
additionally be consideration on how that extension should integrate with
TinkerPop 4 (should likely include introducing a more intentional change in
TP4).
> Extend `asString` to allow just the date part of a datetime to be returned
> --------------------------------------------------------------------------
>
> Key: TINKERPOP-3125
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3125
> Project: TinkerPop
> Issue Type: Improvement
> Components: language
> Environment: Gremlin 3.7.x
> Reporter: Kelvin Lawrence
> Priority: Major
>
> It is sometimes useful to just have the date portion of a timestamp returned
> as just numbers (ISO 8601 style). For example consider
> {code:java}
> g.inject('2024-02-14').asDate().asString(){code}
> which yields
> {code:java}
> Wed Feb 14 00:00:00 UTC 2024{code}
> In some cases it would be nice to just get back `2024-02-14`
> We can write a query to do this mapping using the newer steps found in
> Gremlin 3.7.x but it is a lot of work to generate a slightly modified date
> string.
>
> {code:java}
> g.withSideEffect('m',['Jan':'01','Feb':'02','Mar':'03','Apr':'04','May':'05','Jun':'06',
>
> 'Jul':'07','Aug':'08','Sep':'09','Oct':'10','Nov':'11','Dec':'12']).
>
> inject('2024-Feb-14','2024-Aug-17','2024-Jun-12','2024-Dec-24','2025-Jan-09').as('d').
> format('%{_}-%{_}-%{_}').
> by(substring(0,4)).
> by(select('m').select(select('d').substring(5,8))).
> by(substring(9,11)){code}
> which yields
> {code:java}
> 2024-02-14
> 2024-08-17
> 2024-06-12
> 2024-12-24
> 2025-01-09{code}
> Perhaps we could consider allowing a way for `asString` to be parameterized
> in some way, or perhaps we could extend `format` to be date aware.
> This also raises a related issue that the strings generated by `asString()`
> are not roundtrip-able. Consider this case:
> {code:java}
> g.inject("2025-02-14").asDate().asString()
>
> Fri Feb 14 00:00:00 UTC 2025
> {code}
> but this string cannot be fed back in to a subsequent `asDate` step
> {code:java}
> g.inject('Fri Feb 14 00:00:00 UTC 2025').asDate()
>
> "Can't parse Fri Feb 14 00:00:00 UTC 2025 as Date."
> {code}
>
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
