Dunnymeister commented on issue #772: URL: https://github.com/apache/lucenenet/issues/772#issuecomment-1328714526
I'd like to change DateTools.cs to more closely match the Java source, but there's quite a few differences that I don't want to remove without confirming the project's approach to porting first. Is it right to have additional public methods in Lucene.net that aren't present in the Java source? I ask because there's public methods in Lucene.net DateTools which accept TimeZone as a parameter, which aren't present in Java Lucene 4.8. For example, in the Java source there is only: ```java public static String dateToString(Date date, Resolution resolution) ``` But in Lucene.net there are two: ```c# public static string DateToString(DateTime date, DateResolution resolution) ``` and ```c# public static string DateToString(DateTime date, TimeZoneInfo timeZone, DateResolution resolution) ``` Looking at https://github.com/apache/lucene/blob/releases/lucene-solr/4.8.0/lucene/core/src/java/org/apache/lucene/document/DateTools.java, it looks like DateTools.Resolution contains both the TimeZone and the resolution to return the time in, and the TimeZone is always assumed to be in GMT: ```java Resolution(int formatLen) { this.formatLen = formatLen; // formatLen 10's place: 11111111 // formatLen 1's place: 12345678901234567 this.format = new SimpleDateFormat("yyyyMMddHHmmssSSS".substring(0,formatLen),Locale.ROOT); this.format.setTimeZone(GMT); } ``` Additionally, in commit 46e2437166385837962e809a1675532953e6092b, the DateTools.Resolution enum was denested and renamed DateResolution, but it remains as DateTools.Resolution in the Java source. I'm not sure that this is necessarily a problem, but it is a departure from the source so I wanted to confirm that this was intentional before making any modifications. There's also some tests in Lucene.net's TestDateTools.cs which aren't in the Lucene 4.8 source (e.g. TestDateToolsUTC_Ticks). These tests fail when I restore the old logic. I don't think there's a problem with adding additional tests, but I To summarise: - I'd like to change DateTools.cs to remove any method TimeZone parameters, remove any DateTimeOffset adjustmentsand assume all input dates are UTC, as per the Java Lucene source. - I'd like to remove the tests present in Lucene.net's TestDateTools.cs that aren't present in TestDateTools.java that fail after making the above changes. - I'd like to add an additional test as per the original issue to ensure that DateToString does not throw AggregateException when the input DateTime is 01-01-0001, the DateTime.Kind is Local and and the local timezone is ahead of UTC. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
