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
>
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
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
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
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
+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.
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
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')
