[ 
https://issues.apache.org/jira/browse/LUCENE-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15302689#comment-15302689
 ] 

Steve Rowe commented on LUCENE-7278:
------------------------------------

See [~dawid.weiss]'s suggestions from the past: 
[http://markmail.org/message/diu2wpjiiyrlfgh6].

Here's a patch I'm going to try locally:

{noformat}
diff --git 
a/lucene/spatial-extras/src/test/org/apache/lucene/spatial/prefix/tree/DateRangePrefixTreeTest.java
 
b/lucene/spatial-extras/src/test/org/apache/lucene/spatial/prefix/tree/DateRangePrefixTreeTest.java
index d76454e..022c6de 100644
--- 
a/lucene/spatial-extras/src/test/org/apache/lucene/spatial/prefix/tree/DateRangePrefixTreeTest.java
+++ 
b/lucene/spatial-extras/src/test/org/apache/lucene/spatial/prefix/tree/DateRangePrefixTreeTest.java
@@ -32,7 +32,7 @@ import org.locationtech.spatial4j.shape.SpatialRelation;
 
 public class DateRangePrefixTreeTest extends LuceneTestCase {
 
-  @ParametersFactory
+  @ParametersFactory(argumentFormatting = "calendar=%s")
   public static Iterable<Object[]> parameters() {
     return Arrays.asList(new Object[][]{
         {DateRangePrefixTree.DEFAULT_CAL}, 
{DateRangePrefixTree.JAVA_UTIL_TIME_COMPAT_CAL}
{noformat}

> Make template Calendar configurable in DateRangePrefixTree
> ----------------------------------------------------------
>
>                 Key: LUCENE-7278
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7278
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/spatial-extras
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 6.1
>
>         Attachments: LUCENE_7278.patch, LUCENE_7278.patch
>
>
> DateRangePrefixTree (a SpatialPrefixTree designed for dates and date ranges) 
> currently uses a hard-coded Calendar template for making new instances.  This 
> ought to be configurable so that, for example, the Gregorian change date can 
> be configured.  This is particularly important for compatibility with Java 
> 8's java.time API which uses the Gregorian calendar for all time (there is no 
> use of Julian prior to 1582).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to