[
https://issues.apache.org/jira/browse/TINKERPOP-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-3125:
---------------------------------------
Description:
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 issues 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}
```
was:
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 issues 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}
```
```
> 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 issues 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)
