[
https://issues.apache.org/activemq/browse/AMQNET-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43092#action_43092
]
semog edited comment on AMQNET-82 at 5/28/08 7:44 PM:
----------------------------------------------------------
After extensive testing, I have determined that the submitted functions are
functionally identical to the current implementation (revision 661033). The
submitted implementation has the drawback of being dependent upon .NET 2.0
functions (i.e., IsDaylightSavingTime()).
Further, the current implementation of ToDateTime(long) returns a more complete
DateTime object. Specifically, the current implementation will return a
DateTime object with the Kind property set to Local (which is correct). The
submitted implementation will return a DateTime object with the Kind property
set to Unspecified. While, the Unspecified setting may default to Local, it is
better to be explicit when dealing with date times. The current implementation
is also slightly simpler (no if-statements).
Further, I have not observed any bugs with the current implementation, either
when running with Standard Time or Daylight Saving Time time stamps. As I
mentioned, the existing functions and the submitted functions will convert and
produce identical results, excepting the Kind property.
If a specific error scenario can be shown and reproduced, then this Issue
should be re-opened and a solution can be addressed at that time.
was (Author: semog):
After extensive testing, I have determined that the submitted functions are
functionally identical to the current implementation. The submitted
implementation has the drawback of being dependent upon .NET 2.0 functions
(i.e., IsDaylightSavingTime()).
Further, the current implementation of ToDateTime(long) returns a more complete
DateTime object. Specifically, the current implementation will return a
DateTime object with the Kind property set to Local (which is correct). The
submitted implementation will return a DateTime object with the Kind property
set to Unspecified. While, the Unspecified setting may default to Local, it is
better to be explicit when dealing with date times. The current implementation
is also slightly simpler (no if-statements).
Further, I have not observed any bugs with the current implementation, either
when running with Standard Time or Daylight Saving Time time stamps. As I
mentioned, the existing functions and the submitted functions will convert and
produce identical results, excepting the Kind property.
If a specific error scenario can be shown and reproduced, then this Issue
should be re-opened and a solution can be addressed at that time.
> Apache.NMS.ActiveMQ.Util.DateUtils has incorrect conversion code for .NET to
> Java timestamps and vice versa
> -----------------------------------------------------------------------------------------------------------
>
> Key: AMQNET-82
> URL: https://issues.apache.org/activemq/browse/AMQNET-82
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ Client
> Environment: .NET 3.5 - Java 1.6 - Windows Vista
> Reporter: Brandon Bethke
> Assignee: Jim Gomes
> Attachments: DateUtils.cs
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> The DateUtils class does not correctly convert the ticks of a .NET DateTime
> to a java Date 'ticks' and vice versa. Sorry I dont' have commit access so I
> attached the unoptimized fix. See the attached file for the fix.
> This issue is causing the JMSTimestamp header to get corrupted when a .NET
> client is inserting or retrieving a message into ActiveMQ
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
