Re: [DISCUSS] datetime
I created this for tracking:
https://issues.apache.org/jira/browse/TINKERPOP-2596
On Fri, Jul 23, 2021 at 12:35 PM Joshua Shinavier wrote:
> Well, the string is in ISO 8601, so that's accurate. The serialized values
> are not (unless we use strings instead of longs). Maybe support for ISO
> 8601 proper could be added to GraphBinary as an extended type?
>
> On Fri, Jul 23, 2021 at 8:41 AM Stephen Mallette
> wrote:
>
> > ok - perhaps i shouldn't have declared it as ISO8601 explicitly. In the
> > interest of support for existing serialization perhaps it's best to call
> it
> > unix time and simply have the datetime() accept a string in the
> > YY-MM-DDThh:mm:ss format.
> >
> > On Fri, Jul 23, 2021 at 11:20 AM Joshua Shinavier
> > wrote:
> >
> > > That's fine -- it's just not ISO 8601 in that case; it's Unix time in
> > > milliseconds. ISO 8601 preserves the time zone, and allows
> > sub-millisecond
> > > precision. If we want a Date in Java to map to a .NET DateTime and back
> > > without information loss, then the serialized representation needs to
> be
> > a
> > > string or a structure rather than a number.
> > >
> > > Josh
> > >
> > > On Fri, Jul 23, 2021 at 3:36 AM Stephen Mallette >
> > > wrote:
> > >
> > > > Current support for dates looks like:
> > > >
> > > > Java = java.util.Date()
> > > > Python = datetime()
> > > > Javascript = Date()
> > > > .NET = DateTime()
> > > >
> > > > and given the current serialization model is represented as (taking
> the
> > > > description from GraphBinary docs) an 8-byte two’s complement signed
> > > > integer representing a millisecond-precision offset from the unix
> > epoch:
> > > >
> > > > 00 00 00 00 00 00 00 00: The moment in time 1970-01-01T00:00:00.000Z.
> > > > ff ff ff ff ff ff ff ff: The moment in time 1969-12-31T23:59:59.999Z.
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Jul 22, 2021 at 7:16 PM Joshua Shinavier
> > > > wrote:
> > > >
> > > > > 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
> > > > > > > > >
> > > > > > 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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] datetime
Well, the string is in ISO 8601, so that's accurate. The serialized values
are not (unless we use strings instead of longs). Maybe support for ISO
8601 proper could be added to GraphBinary as an extended type?
On Fri, Jul 23, 2021 at 8:41 AM Stephen Mallette
wrote:
> ok - perhaps i shouldn't have declared it as ISO8601 explicitly. In the
> interest of support for existing serialization perhaps it's best to call it
> unix time and simply have the datetime() accept a string in the
> YY-MM-DDThh:mm:ss format.
>
> On Fri, Jul 23, 2021 at 11:20 AM Joshua Shinavier
> wrote:
>
> > That's fine -- it's just not ISO 8601 in that case; it's Unix time in
> > milliseconds. ISO 8601 preserves the time zone, and allows
> sub-millisecond
> > precision. If we want a Date in Java to map to a .NET DateTime and back
> > without information loss, then the serialized representation needs to be
> a
> > string or a structure rather than a number.
> >
> > Josh
> >
> > On Fri, Jul 23, 2021 at 3:36 AM Stephen Mallette
> > wrote:
> >
> > > Current support for dates looks like:
> > >
> > > Java = java.util.Date()
> > > Python = datetime()
> > > Javascript = Date()
> > > .NET = DateTime()
> > >
> > > and given the current serialization model is represented as (taking the
> > > description from GraphBinary docs) an 8-byte two’s complement signed
> > > integer representing a millisecond-precision offset from the unix
> epoch:
> > >
> > > 00 00 00 00 00 00 00 00: The moment in time 1970-01-01T00:00:00.000Z.
> > > ff ff ff ff ff ff ff ff: The moment in time 1969-12-31T23:59:59.999Z.
> > >
> > >
> > >
> > >
> > > On Thu, Jul 22, 2021 at 7:16 PM Joshua Shinavier
> > > wrote:
> > >
> > > > 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
> > > > > > >
> > > > > 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] datetime
ok - perhaps i shouldn't have declared it as ISO8601 explicitly. In the
interest of support for existing serialization perhaps it's best to call it
unix time and simply have the datetime() accept a string in the
YY-MM-DDThh:mm:ss format.
On Fri, Jul 23, 2021 at 11:20 AM Joshua Shinavier wrote:
> That's fine -- it's just not ISO 8601 in that case; it's Unix time in
> milliseconds. ISO 8601 preserves the time zone, and allows sub-millisecond
> precision. If we want a Date in Java to map to a .NET DateTime and back
> without information loss, then the serialized representation needs to be a
> string or a structure rather than a number.
>
> Josh
>
> On Fri, Jul 23, 2021 at 3:36 AM Stephen Mallette
> wrote:
>
> > Current support for dates looks like:
> >
> > Java = java.util.Date()
> > Python = datetime()
> > Javascript = Date()
> > .NET = DateTime()
> >
> > and given the current serialization model is represented as (taking the
> > description from GraphBinary docs) an 8-byte two’s complement signed
> > integer representing a millisecond-precision offset from the unix epoch:
> >
> > 00 00 00 00 00 00 00 00: The moment in time 1970-01-01T00:00:00.000Z.
> > ff ff ff ff ff ff ff ff: The moment in time 1969-12-31T23:59:59.999Z.
> >
> >
> >
> >
> > On Thu, Jul 22, 2021 at 7:16 PM Joshua Shinavier
> > wrote:
> >
> > > 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 >
> > > wrote:
> > >
> > > > +1 from me as well.
> > > >
> > > > On Thu, Jul 22, 2021 at 8:28 AM Kelvin Lawrence
> > > > >
> > > > 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.
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] datetime
That's fine -- it's just not ISO 8601 in that case; it's Unix time in
milliseconds. ISO 8601 preserves the time zone, and allows sub-millisecond
precision. If we want a Date in Java to map to a .NET DateTime and back
without information loss, then the serialized representation needs to be a
string or a structure rather than a number.
Josh
On Fri, Jul 23, 2021 at 3:36 AM Stephen Mallette
wrote:
> Current support for dates looks like:
>
> Java = java.util.Date()
> Python = datetime()
> Javascript = Date()
> .NET = DateTime()
>
> and given the current serialization model is represented as (taking the
> description from GraphBinary docs) an 8-byte two’s complement signed
> integer representing a millisecond-precision offset from the unix epoch:
>
> 00 00 00 00 00 00 00 00: The moment in time 1970-01-01T00:00:00.000Z.
> ff ff ff ff ff ff ff ff: The moment in time 1969-12-31T23:59:59.999Z.
>
>
>
>
> On Thu, Jul 22, 2021 at 7:16 PM Joshua Shinavier
> wrote:
>
> > 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
> > wrote:
> >
> > > +1 from me as well.
> > >
> > > On Thu, Jul 22, 2021 at 8:28 AM Kelvin Lawrence
> > >
> > > 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.
> > > >
> > >
> >
>
Re: [DISCUSS] datetime
Current support for dates looks like:
Java = java.util.Date()
Python = datetime()
Javascript = Date()
.NET = DateTime()
and given the current serialization model is represented as (taking the
description from GraphBinary docs) an 8-byte two’s complement signed
integer representing a millisecond-precision offset from the unix epoch:
00 00 00 00 00 00 00 00: The moment in time 1970-01-01T00:00:00.000Z.
ff ff ff ff ff ff ff ff: The moment in time 1969-12-31T23:59:59.999Z.
On Thu, Jul 22, 2021 at 7:16 PM Joshua Shinavier wrote:
> 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
> wrote:
>
> > +1 from me as well.
> >
> > On Thu, Jul 22, 2021 at 8:28 AM Kelvin Lawrence >
> > 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.
> > >
> >
>
Re: [DISCUSS] datetime
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
wrote:
> +1 from me as well.
>
> On Thu, Jul 22, 2021 at 8:28 AM Kelvin Lawrence
> 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.
> >
>
Re: [DISCUSS] datetime
+1 from me as well.
On Thu, Jul 22, 2021 at 8:28 AM Kelvin Lawrence
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.
>
Re: [DISCUSS] datetime
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
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.
[DISCUSS] datetime
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.
