Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
>`gx:ZoneOffset` - How about deserializing to TimeSpan?
TimeZone.GetUtcOffset also returns a TimeSpan
Seems reasonable.
>`gx:InetAddress` - I'm not sure what we can expect to get in @value here
as the example shows localhost
It would be great to have some more insight here. What was initially
intended?
>`gx:MonthDay, gx:Year, and gx:YearMonth` - I don't know how often users
will return these types, but we may simply deserialize them to DateTime.
I disagree. That would introduce data that was simply not there originally.
>`gx:OffsetTime` - How about deserializing this to DateTimeOffset and
leaving the date 0000-01-01 or DateTimeOffset.Min or something like that?
Again, that information is simply not there.
>`gx:ZonedDateTime` - We would loose some information...
Right...losing information is not good as well.
On an unrelated issue, someone on JIRA commented that while a feature might
desirable in principle, it is unclear which current database vendor will
actually implement it....maybe we should deal with this issue the same way. As
long as nobody needs it urgently for their database, it may remain unsupported.
What do you think?
---
