You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2021/08/04 14:51:55 UTC

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 <jo...@fortytwo.net> 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 <sp...@gmail.com>
> 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 <jo...@fortytwo.net>
> > 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 <spmallette@gmail.com
> >
> > > 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 <jo...@fortytwo.net>
> > > > 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 <
> > dave@bechberger.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > +1 from me as well.
> > > > > >
> > > > > > On Thu, Jul 22, 2021 at 8:28 AM Kelvin Lawrence
> > > > <gfxman@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
> > > <
> > > > > > > spmallette@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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>