[
https://issues.apache.org/jira/browse/IGNITE-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943269#comment-14943269
]
Pavel Tupitsyn commented on IGNITE-1613:
-----------------------------------------
DateTime:
* Bottleneck is ToUniversalTime() call. We can't get rid of it or cache UTC
ticks offset because it can lead to bugs with daylight savings and such.
* Current marshalling format is (long milliseconds) + (int nanoSecondPart).
Java uses it for both Date (which is expressed as a single long, in
milliseconds) and Timestamp (which is in nanoseconds)
* .Net DateTime is a single long, in ticks. 1 tick = 100 nanoseconds. So
interop format carries more info than we need, and Write->Read roundtrip will
always return the same value
* We could separate Date and Timestamp serialization in Java to improve
performance, but it would complicate .Net interop since (Java Date precision) <
(.Net DateTime precision) < (Java Timestamp precision).
> Platform .Net: Investigate Guid/DateTime/String interoperability with Java
> --------------------------------------------------------------------------
>
> Key: IGNITE-1613
> URL: https://issues.apache.org/jira/browse/IGNITE-1613
> Project: Ignite
> Issue Type: Task
> Components: interop
> Affects Versions: ignite-1.5
> Reporter: Pavel Tupitsyn
> Assignee: Pavel Tupitsyn
> Fix For: ignite-1.5
>
>
> Currently in .Net we:
> * write Guid and DateTime in Java format
> * calculate string hash code for field names with Java algorithm on each call
> Need to investigate if the following makes sense:
> 1) In .Net always write Guid and DateTime in native .Net format as fast as
> possible; Make Java understand that format. (Not every Guid written in .Net
> will be read in Java, so we can win time).
> 2) Cache string hashcodes somehow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
