I think that works so long as there is a common type which would exist in
each GLV and which datetime() would parse *to*. This type could then be
mapped into GLV-native types as desired. An easy choice for the common type
would be 64-bit Unix timestamps in milliseconds, but this does not capture
arbitrary precision (as ISO 8601 does). If all we want is milliseconds,
then maybe call the function dateTimeToMillis() or such. If we want a
structured representation of the dateTime, then we need a way of providing
the type in each language in an equivalent way (doable, as I have
illustrated, but needs doing).
Josh
On Thu, Jul 22, 2021 at 10:45 AM David Bechberger <d...@bechberger.com>
wrote:
> +1 from me as well.
>
> On Thu, Jul 22, 2021 at 8:28 AM Kelvin Lawrence <gfx...@yahoo.com.invalid>
> wrote:
>
> > A big +1 from me for this. As much as possible making Gremlin a language
> > that does not depend on closures for things like dates and string
> > manipulation will help with parity when compared to other query
> languages.
> > Kelvin
> >
> >
> > On Wednesday, July 21, 2021, 07:49:17 AM CDT, Stephen Mallette <
> > spmalle...@gmail.com> wrote:
> >
> > One of the things precluding a move toward a more pure usage of
> > gremlin-language in place of groovy scripts is a way to instantiate a
> > date/time. It seems simple enough to just include a datetime() function
> in
> > the grammar that will parse a ISO-8601 formatted dates:
> >
> > datetime('2021-07-21')
> > datetime('2021-07-21T01:12:59')
> > datetime('2021-07-21T01:12:59+0500')
> >
> > Each language can retain its own method for producing datetime that it
> > already has.
> >
>
