NightOwl888 commented on code in PR #914:
URL: https://github.com/apache/lucenenet/pull/914#discussion_r1493362598
##########
src/Lucene.Net.Tests/Search/TestCustomSearcherSort.cs:
##########
@@ -251,7 +245,7 @@ internal RandomGen(TestCustomSearcherSort outerInstance,
Random random)
// Just to generate some different Lucene Date strings
internal virtual string LuceneDate
- => DateTools.TimeToString((DateTime.Now.Ticks /
TimeSpan.TicksPerMillisecond) + random.Next() - int.MinValue,
DateResolution.DAY);
+ => DateTools.TimeToString((@base.Ticks /
TimeSpan.TicksPerMillisecond) + random.Next() - int.MinValue,
DateResolution.DAY);
Review Comment:
This is not correct to generate a date for ticks. The default now assumes to
use milliseconds since Unix epoch (as it is in Lucene). Please use:
```c#
internal virtual string LuceneDate
=>
DateTools.TimeToString(DateTools.TicksToUnixTimeMilliseconds(@base.Ticks) +
random.Next() - int.MinValue, DateResolution.DAY);
```
It is possible that the following would be equivalent, but it would need to
be tested to confirm:
```c#
internal virtual string LuceneDate
=> DateTools.TimeToString(J2N.Time.GetMillisecondsSinceUnixEpoch(@base)
+ random.Next() - int.MinValue, DateResolution.DAY);
```
```c#
internal virtual string LuceneDate
=> DateTools.TimeToString(@base.Ticks + random.Next() - int.MinValue,
DateResolution.DAY, NumericRepresentation.TICKS);
```
The `DateTools` representation for input `long` and output `long` is now
consistent. In Lucene.Net 3.x it was expecting ticks as milliseconds as input
and was outputting ticks. We have built in legacy support for
`TICKS_AS_MILLISECONDS`, but we shouldn't be using it in code going forward.
--
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
