[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user asfgit closed the pull request at: https://github.com/apache/lucene-solr/pull/428 --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r208249177
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java
---
@@ -232,23 +220,22 @@ public void testParseFrenchDate() throws Exception {
assertNull(schema.getFieldOrNull("not_in_schema"));
String frenchDateString = "le vendredi 15 janvier 2010";
String dateString = "2010-01-15T00:00:00.000Z";
-DateTimeFormatter dateTimeFormatter = ISODateTimeFormat.dateTime();
-DateTime dateTime = dateTimeFormatter.parseDateTime(dateString);
SolrInputDocument d =
processAdd("parse-french-date-UTC-defaultTimeZone-no-run-processor",
doc(f("id", "88"), f("not_in_schema",
frenchDateString)));
assertNotNull(d);
assertTrue(d.getFieldValue("not_in_schema") instanceof Date);
-assertEquals(dateTime.getMillis(),
((Date)d.getFieldValue("not_in_schema")).getTime());
+assertEquals(Instant.parse(dateString),
((Date)d.getFieldValue("not_in_schema")).toInstant());
}
public void testFailedParseMixedDate() throws Exception {
IndexSchema schema = h.getCore().getLatestSchema();
assertNull(schema.getFieldOrNull("not_in_schema"));
-DateTimeFormatter dateTimeFormatter =
ISODateTimeFormat.dateOptionalTimeParser().withZoneUTC();
+DateTimeFormatter dateTimeFormatter =
DateTimeFormatter.ofPattern("-MM-dd['T'HH:mm][:ss.SSSz]",
Locale.ROOT).withZone(ZoneOffset.UTC);
--- End diff --
This particular dateTimeFormatter shows up in a bunch of places in this
test, so I'll put it in a field constant. Likewise I'll add a simple
parse(DateTimeFormatter, String dateString) method to reduce duplication of
specifying so many date time objects in parseBest.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r208248179
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java
---
@@ -171,59 +162,56 @@ public void testParseUSPacificDate() throws Exception
{
doc(f("id", "288"),
f("not_in_schema", dateString)));
assertNotNull(d);
assertTrue(d.getFieldValue("not_in_schema") instanceof Date);
-assertEquals(dateStringUTC,
- (new
DateTime(((Date)d.getFieldValue("not_in_schema")).getTime(),DateTimeZone.UTC)).toString());
+assertEquals(dateStringUTC,
+
(ZonedDateTime.ofInstant(((Date)d.getFieldValue("not_in_schema")).toInstant(),
ZoneOffset.UTC)).format(DateTimeFormatter.ofPattern("-MM-dd'T'HH:mm:ss.SSSz",
Locale.ROOT)));
--- End diff --
This can simply be:
```
assertEquals(Instant.parse("2010-08-09T07:00:00.000Z"),
((Date)d.getFieldValue("not_in_schema")).toInstant());
```
Compare Instants; needn't do any formatting which adds complication.
(I'll do it)
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/428#discussion_r207745675 --- Diff: solr/core/src/test-files/solr/collection1/conf/solrconfig-parsing-update-processor-chains.xml --- @@ -29,43 +29,43 @@ - -MM-dd'T'HH:mm:ss.SSSZ --- End diff -- Changed this to single lower case z. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207742429
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java
---
@@ -171,36 +162,36 @@ public void testParseUSPacificDate() throws Exception
{
doc(f("id", "288"),
f("not_in_schema", dateString)));
assertNotNull(d);
assertTrue(d.getFieldValue("not_in_schema") instanceof Date);
-assertEquals(dateStringUTC,
- (new
DateTime(((Date)d.getFieldValue("not_in_schema")).getTime(),DateTimeZone.UTC)).toString());
+assertEquals(dateStringUTC,
+
(ZonedDateTime.ofInstant(((Date)d.getFieldValue("not_in_schema")).toInstant(),
ZoneOffset.UTC)).format(DateTimeFormatter.ofPattern("-MM-dd'T'HH:mm:ss.SSSZ",
Locale.ROOT)));
}
public void testParseDateFormats() throws Exception {
String[] formatExamples = {
--- End diff --
Added :)
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207742308
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -172,4 +181,34 @@ public void init(NamedList args) {
return (null == type) || type instanceof DateValueFieldType;
};
}
+
+ public static void validateFormatter(DateTimeFormatter formatter) {
+// check it's valid via round-trip
+try {
+ parseInstant(formatter, formatter.format(Instant.now()));
+} catch (Exception e) {
+ throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
+ "Bad or unsupported pattern: " +
formatter.toFormat().toString(), e);
+}
+ }
+
+ private static Instant parseInstant(DateTimeFormatter formatter, String
dateStr) {
+final TemporalAccessor temporalAccessor = formatter.parse(dateStr);
+// parsed successfully. But is it a full instant or just to the day?
+if (temporalAccessor.isSupported(ChronoField.INSTANT_SECONDS)) { //
has time
+ // has offset time
+ if(temporalAccessor.isSupported(ChronoField.OFFSET_SECONDS)) {
--- End diff --
Oh wow can't believe I missed that. This seems so much more robust then the
previous version.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207725540
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -172,4 +181,34 @@ public void init(NamedList args) {
return (null == type) || type instanceof DateValueFieldType;
};
}
+
+ public static void validateFormatter(DateTimeFormatter formatter) {
+// check it's valid via round-trip
+try {
+ parseInstant(formatter, formatter.format(Instant.now()));
+} catch (Exception e) {
+ throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
+ "Bad or unsupported pattern: " +
formatter.toFormat().toString(), e);
+}
+ }
+
+ private static Instant parseInstant(DateTimeFormatter formatter, String
dateStr) {
+final TemporalAccessor temporalAccessor = formatter.parse(dateStr);
+// parsed successfully. But is it a full instant or just to the day?
+if (temporalAccessor.isSupported(ChronoField.INSTANT_SECONDS)) { //
has time
+ // has offset time
+ if(temporalAccessor.isSupported(ChronoField.OFFSET_SECONDS)) {
--- End diff --
I worked on test program demonstrating the JDK issue and I see now that
this has already been reported:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8177021(we should put
a comment about this in the code). It's nice to see it has been fixed in JDK 9
(and my test program revealed that too).
During my exploration of this, I discovered that a lowercase 'z' in the
pattern can parse various formats, and so can "VV". I replaced the 5-'Z'
patterns in the test file with a single lower 'z' and the tests passed. FYI
this part of the javadocs is helpful:
https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatterBuilder.html#appendPattern-java.lang.String-
(builder has more detail than the DateTimeFormatter).
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207724560
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java
---
@@ -171,36 +162,36 @@ public void testParseUSPacificDate() throws Exception
{
doc(f("id", "288"),
f("not_in_schema", dateString)));
assertNotNull(d);
assertTrue(d.getFieldValue("not_in_schema") instanceof Date);
-assertEquals(dateStringUTC,
- (new
DateTime(((Date)d.getFieldValue("not_in_schema")).getTime(),DateTimeZone.UTC)).toString());
+assertEquals(dateStringUTC,
+
(ZonedDateTime.ofInstant(((Date)d.getFieldValue("not_in_schema")).toInstant(),
ZoneOffset.UTC)).format(DateTimeFormatter.ofPattern("-MM-dd'T'HH:mm:ss.SSSZ",
Locale.ROOT)));
}
public void testParseDateFormats() throws Exception {
String[] formatExamples = {
--- End diff --
I just realized these formats are duplicated identically from the config
file -- large code duplication :-( A comment that this is the case would be
helpful to reviewers.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207724539
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -172,4 +181,34 @@ public void init(NamedList args) {
return (null == type) || type instanceof DateValueFieldType;
};
}
+
+ public static void validateFormatter(DateTimeFormatter formatter) {
+// check it's valid via round-trip
+try {
+ parseInstant(formatter, formatter.format(Instant.now()));
+} catch (Exception e) {
+ throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
+ "Bad or unsupported pattern: " +
formatter.toFormat().toString(), e);
+}
+ }
+
+ private static Instant parseInstant(DateTimeFormatter formatter, String
dateStr) {
+final TemporalAccessor temporalAccessor = formatter.parse(dateStr);
+// parsed successfully. But is it a full instant or just to the day?
+if (temporalAccessor.isSupported(ChronoField.INSTANT_SECONDS)) { //
has time
+ // has offset time
+ if(temporalAccessor.isSupported(ChronoField.OFFSET_SECONDS)) {
--- End diff --
I'm feeling pretty confident about the following:
```
private static Instant parseInstant(DateTimeFormatter formatter, String
dateStr) {
final TemporalAccessor temporal = formatter.parse(dateStr);
// Get Date; mandatory
LocalDate date = temporal.query(TemporalQueries.localDate());//mandatory
if (date == null) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
"Date (year, month, day) is mandatory: " +
formatter.toFormat().toString());
}
// Get Time; optional
LocalTime time = temporal.query(TemporalQueries.localTime());
if (time == null) {
time = LocalTime.MIN;
}
final LocalDateTime localDateTime = LocalDateTime.of(date, time);
// Get Zone Offset; optional
ZoneOffset offset = temporal.query(TemporalQueries.offset());
if (offset == null) {
// no Zone offset; get Zone ID
ZoneId zoneId = temporal.query(TemporalQueries.zone());
if (zoneId == null) {
zoneId = formatter.getZone();
if (zoneId == null) {
zoneId = ZoneOffset.UTC;
}
}
return localDateTime.atZone(zoneId).toInstant();
} else {
return localDateTime.toInstant(offset);
}
}
```
This dispenses with trying to use INSTANT_SECONDS which would be a
short-cut/optimization but we can't trust that due to my previous comment.
What's needed in the tests is an input string that actually provides an
interesting timezone and/or offset, plus a default timezone of something other
than UTC to show that we ignore that and use the zone or offset provided in the
value. I don't see any test that does that; the tests all provide values of
referring to `Z` or zeroes (equivalent) -- which doesn't exercise the
defaulting logic. An example value taken from SOLR-12561's patch is: `Fri Oct
7 05:14:15 AKDT 2005` (Alaska).
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207697969
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java
---
@@ -912,4 +904,18 @@ public void testCascadingParsers() throws Exception {
}
assertTrue(mixedDates.isEmpty());
}
+
+ private Date temporalToDate(TemporalAccessor in, ZoneId timeZoneId) {
+if(in instanceof OffsetDateTime) {
+ return Date.from(((OffsetDateTime) in).toInstant());
+} else if(in instanceof ZonedDateTime) {
+ return Date.from(((ZonedDateTime)
in).withZoneSameInstant(timeZoneId).toInstant());
--- End diff --
This line should be `return Date.from(((ZonedDateTime) in).toInstant());`
-- needn't use timeZoneId (tests pass). It's functionally equivalent but
avoids a needless intermediate step.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207700607
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -172,4 +181,34 @@ public void init(NamedList args) {
return (null == type) || type instanceof DateValueFieldType;
};
}
+
+ public static void validateFormatter(DateTimeFormatter formatter) {
+// check it's valid via round-trip
+try {
+ parseInstant(formatter, formatter.format(Instant.now()));
+} catch (Exception e) {
+ throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
+ "Bad or unsupported pattern: " +
formatter.toFormat().toString(), e);
+}
+ }
+
+ private static Instant parseInstant(DateTimeFormatter formatter, String
dateStr) {
+final TemporalAccessor temporalAccessor = formatter.parse(dateStr);
+// parsed successfully. But is it a full instant or just to the day?
+if (temporalAccessor.isSupported(ChronoField.INSTANT_SECONDS)) { //
has time
+ // has offset time
+ if(temporalAccessor.isSupported(ChronoField.OFFSET_SECONDS)) {
--- End diff --
This part, checking OFFSET_SECONDS ought not to be present here, I think.
INSTANT_SECONDS should be self-sufficient. See
java.time.Parsed.resolveInstant() which gives clues as to what's going on. The
override "zone" we set earlier on the formatter is taking precedence over the
OFFSET_SECONDS, leading you to try this as a work-around. I wonder if this is
a JDK bug; IMO it ought to be flipped.
I think we may need to be smarter about when to set the default zone on the
formatter and when not to. If the format specifies the zone or has a 'Z'
literal, then I think we don't; otherwise we set it. Or we don't set it at all
there and incorporate it here in parseInstant() which may be safer. I'll
propose something more concrete after I get some sleep; I have some WIP code.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207699324
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java
---
@@ -209,9 +200,8 @@ public void testParseDateFormats() throws Exception {
IndexSchema schema = h.getCore().getLatestSchema();
assertNotNull(schema.getFieldOrNull("dateUTC_dt")); // should match
"*_dt" dynamic field
-String dateTimePattern = "-MM-dd'T'HH:mm:ss.SSSZ";
-DateTimeFormatter dateTimeFormatterUTC =
DateTimeFormat.forPattern(dateTimePattern);
-DateTime dateTimeUTC =
dateTimeFormatterUTC.parseDateTime(formatExamples[1]);
+String dateTimePattern = "-MM-dd'T'HH:mm:ss.SSSZ";
+Instant UTCInstant = Instant.parse(formatExamples[1]);
--- End diff --
IMO `UTCInstant` is suggestive that somehow other Instants might not be UTC
yet this one is. An instant is an unambiguous instant in time that has no
relation to time zones. Someone might _express_ / format an instant in a zone,
but the instant itself is neutral to the notion. Perhaps "theInstant" or
"expectInstant" is better as it's the "expect" side of the assert we test in
the loop below.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207692433
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java
---
@@ -50,10 +55,9 @@ public void testParseDateRoundTrip() throws Exception {
String dateString = "2010-11-12T13:14:15.168Z";
SolrInputDocument d = processAdd("parse-date", doc(f("id", "9"),
f("date_dt", dateString)));
assertNotNull(d);
-DateTimeFormatter dateTimeFormatter = ISODateTimeFormat.dateTime();
-DateTime dateTime = dateTimeFormatter.parseDateTime(dateString);
+ZonedDateTime localDateTime = ZonedDateTime.parse(dateString,
DateTimeFormatter.ISO_DATE_TIME);
assertTrue(d.getFieldValue("date_dt") instanceof Date);
-assertEquals(dateTime.getMillis(), ((Date)
d.getFieldValue("date_dt")).getTime());
+
assertEquals(localDateTime.withZoneSameInstant(ZoneOffset.UTC).toInstant().toEpochMilli(),
((Date) d.getFieldValue("date_dt")).getTime());
--- End diff --
You are right. I have pushed a commit to address this issue. I will try and
look into other areas that could be improved/simplified.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/428#discussion_r207691834 --- Diff: solr/licenses/joda-time-NOTICE.txt --- @@ -1,5 +0,0 @@ -= --- End diff -- Sure thing. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207645614
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java
---
@@ -116,12 +118,12 @@ public void
testParseDateNonUTCdefaultTimeZoneRoundTrip() throws Exception {
("parse-date-non-UTC-defaultTimeZone", doc(f("id", "99"),
f("dateUTC_dt", dateStringUTC),
f("dateNoTimeZone_dt",
dateStringNoTimeZone)));
assertNotNull(d);
-String pattern = "-MM-dd'T'HH:mm:ss.SSSZ";
-DateTimeFormatter dateTimeFormatterUTC =
DateTimeFormat.forPattern(pattern);
-DateTime dateTimeUTC =
dateTimeFormatterUTC.parseDateTime(dateStringUTC);
+String pattern = "-MM-dd'T'HH:mm:ss.SSSZ";
+DateTimeFormatter UTCForamatter = DateTimeFormatter.ofPattern(pattern,
Locale.ROOT).withZone(ZoneId.of("America/New_York"));
+OffsetDateTime dateTimeOffsetUTC = OffsetDateTime.parse(dateStringUTC,
UTCForamatter);
assertTrue(d.getFieldValue("dateUTC_dt") instanceof Date);
assertTrue(d.getFieldValue("dateNoTimeZone_dt") instanceof Date);
-assertEquals(dateTimeUTC.getMillis(), ((Date)
d.getFieldValue("dateUTC_dt")).getTime());
+assertEquals(dateTimeOffsetUTC.toInstant().toEpochMilli(), ((Date)
d.getFieldValue("dateUTC_dt")).getTime());
--- End diff --
I stared at this test for awhile and came to the conclusion that the
UTCFormatter related stuff is unnecessary (those 3 lines above), and so is this
assertEquals line. You can remove them. Those several lines were internal
confusing jirations that didn't actually really test anything other than
demonstrate how one can use java.time (formerly joda). The real meat of this
test IMO is the assertQ with the string constants, which is good.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207624001
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -172,4 +179,21 @@ public void init(NamedList args) {
return (null == type) || type instanceof DateValueFieldType;
};
}
+
+ private static Instant parseInstant(DateTimeFormatter formatter, String
dateStr) {
+final TemporalAccessor temporalAccessor = formatter.parse(dateStr);
+// parsed successfully. But is it a full instant or just to the day?
+if(temporalAccessor.isSupported(ChronoField.OFFSET_SECONDS)) {
--- End diff --
Firstly, I think INSTANT_SECONDS should be very first check (presumed fast
path).
Secondly, I'm doubtful that OFFSET_SECONDS is the correct thing to check
on. I guess I'd have to use a debugger to have any confidence. Hmm; looking
at `java.time.OffsetDateTime#from` is interesting. maybe grab
`temporal.query(TemporalQueries.localDate()` (and insist we find it otherwise
pattern is impossibly vague?), and then attempt to get the time optionally
(otherwise assume start of day) and the timezone optionally (default to
configured/default zone). Maybe that is right.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207641129
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/ParsingFieldUpdateProcessorsTest.java
---
@@ -50,10 +55,9 @@ public void testParseDateRoundTrip() throws Exception {
String dateString = "2010-11-12T13:14:15.168Z";
SolrInputDocument d = processAdd("parse-date", doc(f("id", "9"),
f("date_dt", dateString)));
assertNotNull(d);
-DateTimeFormatter dateTimeFormatter = ISODateTimeFormat.dateTime();
-DateTime dateTime = dateTimeFormatter.parseDateTime(dateString);
+ZonedDateTime localDateTime = ZonedDateTime.parse(dateString,
DateTimeFormatter.ISO_DATE_TIME);
assertTrue(d.getFieldValue("date_dt") instanceof Date);
-assertEquals(dateTime.getMillis(), ((Date)
d.getFieldValue("date_dt")).getTime());
+
assertEquals(localDateTime.withZoneSameInstant(ZoneOffset.UTC).toInstant().toEpochMilli(),
((Date) d.getFieldValue("date_dt")).getTime());
--- End diff --
Simply change the left arg to `Instant.parse(dateString)` (and call
toInstant() on the right arg instead of getTime()), and remove the couple lines
above that are no longer needed :-)
Part of the work involved, I think, isn't always doing a direct Joda ->
java.time API translation, but it's also recognizing when the code in question
is needlessly verbose and making it better. I try to take that philosophy with
any code maintenance. There's a lot of cases in this test suite where you can
apply the above technique to remove needless time API machinery that is
needless.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207625264
--- Diff:
solr/core/src/test/org/apache/solr/update/processor/AddSchemaFieldsUpdateProcessorFactoryTest.java
---
@@ -63,8 +63,8 @@ public void testSingleField() throws Exception {
final String fieldName = "newfield1";
assertNull(schema.getFieldOrNull(fieldName));
String dateString = "2010-11-12T13:14:15.168Z";
--- End diff --
This test doesn't even care about formatting, it just wants some Date type.
So just use `new Date()` :-)
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207621885
--- Diff: solr/core/src/java/org/apache/solr/core/ConfigSetService.java ---
@@ -212,12 +213,12 @@ public SchemaCaching(SolrResourceLoader loader, Path
configSetBase) {
super(loader, configSetBase);
}
-public static final DateTimeFormatter cacheKeyFormatter =
DateTimeFormat.forPattern("MMddHHmmss");
+public static final DateTimeFormatter cacheKeyFormatter =
DateTimeFormatter.ofPattern("MMddHHmmss", Locale.ROOT);
public static String cacheName(Path schemaFile) throws IOException {
long lastModified = Files.getLastModifiedTime(schemaFile).toMillis();
return String.format(Locale.ROOT, "%s:%s",
-schemaFile.toString(),
cacheKeyFormatter.print(lastModified));
+schemaFile.toString(),
Instant.ofEpochMilli(lastModified).atZone(ZoneOffset.UTC).format(cacheKeyFormatter));
--- End diff --
I think the 2nd arg should be simplified to this:
`Instant.ofEpochMilli(lastModified).toString()`
This removes the need for a cacheKeyFormatter. My only concern before
mentioning this originally was that I did't know what happens with this
formatted info... did it need to get reparsed somewhere or stored ZooKeeper.
Neither of those things; it's just a portion of cache key. So lets keep this
super simple.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207622324
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -144,15 +149,17 @@ public void init(NamedList args) {
}
Object defaultTimeZoneParam = args.remove(DEFAULT_TIME_ZONE_PARAM);
-DateTimeZone defaultTimeZone = DateTimeZone.UTC;
+ZoneId defaultTimeZone = ZoneOffset.UTC;
if (null != defaultTimeZoneParam) {
- defaultTimeZone =
DateTimeZone.forID(defaultTimeZoneParam.toString());
+ defaultTimeZone = ZoneId.of(defaultTimeZoneParam.toString());
}
Collection formatsParam = args.removeConfigArgs(FORMATS_PARAM);
if (null != formatsParam) {
for (String value : formatsParam) {
-formats.put(value,
DateTimeFormat.forPattern(value).withZone(defaultTimeZone).withLocale(locale));
+DateTimeFormatter formatter = new
DateTimeFormatterBuilder().parseCaseInsensitive()
+
.appendPattern(value).toFormatter(locale).withZone(defaultTimeZone);
+formats.put(value, formatter);
--- End diff --
Please add a round-trip check so we can see if parseInstant will handle the
format. I think I had this in my other patch; you can see there. This way if
someone puts in an invalid pattern (i.e. something silly like only the month),
they get notified up front that the format is invalid.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/428#discussion_r207620961 --- Diff: solr/licenses/joda-time-NOTICE.txt --- @@ -1,5 +0,0 @@ -= --- End diff -- Good but there are two other files in this directory starting with joda that should be removed as well. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207591947
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -115,9 +123,10 @@ protected Object mutateValue(Object srcVal) {
for (Map.Entry format :
formats.entrySet()) {
DateTimeFormatter parser = format.getValue();
try {
- DateTime dateTime = parser.parseDateTime(srcStringVal);
- return dateTime.withZone(DateTimeZone.UTC).toDate();
-} catch (IllegalArgumentException e) {
+ TemporalAccessor parsedTemporalDate =
parser.parseBest(srcStringVal, OffsetDateTime::from,
--- End diff --
Alright.
Hopefully this one is close to being merged. Any other problems you for see
here?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207590707
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -115,9 +123,10 @@ protected Object mutateValue(Object srcVal) {
for (Map.Entry format :
formats.entrySet()) {
DateTimeFormatter parser = format.getValue();
try {
- DateTime dateTime = parser.parseDateTime(srcStringVal);
- return dateTime.withZone(DateTimeZone.UTC).toDate();
-} catch (IllegalArgumentException e) {
+ TemporalAccessor parsedTemporalDate =
parser.parseBest(srcStringVal, OffsetDateTime::from,
--- End diff --
SOLR-12591 is next (docs + tests), then removal in SOLR-12593
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207585634
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -115,9 +123,10 @@ protected Object mutateValue(Object srcVal) {
for (Map.Entry format :
formats.entrySet()) {
DateTimeFormatter parser = format.getValue();
try {
- DateTime dateTime = parser.parseDateTime(srcStringVal);
- return dateTime.withZone(DateTimeZone.UTC).toDate();
-} catch (IllegalArgumentException e) {
+ TemporalAccessor parsedTemporalDate =
parser.parseBest(srcStringVal, OffsetDateTime::from,
--- End diff --
Ok, would this be part of another ticket?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207577229
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -115,9 +123,10 @@ protected Object mutateValue(Object srcVal) {
for (Map.Entry format :
formats.entrySet()) {
DateTimeFormatter parser = format.getValue();
try {
- DateTime dateTime = parser.parseDateTime(srcStringVal);
- return dateTime.withZone(DateTimeZone.UTC).toDate();
-} catch (IllegalArgumentException e) {
+ TemporalAccessor parsedTemporalDate =
parser.parseBest(srcStringVal, OffsetDateTime::from,
--- End diff --
I determined the functionality in the "extraction" module should simply go
away in lieu of this URP, so there will be no duplication.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207465468
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -115,9 +123,10 @@ protected Object mutateValue(Object srcVal) {
for (Map.Entry format :
formats.entrySet()) {
DateTimeFormatter parser = format.getValue();
try {
- DateTime dateTime = parser.parseDateTime(srcStringVal);
- return dateTime.withZone(DateTimeZone.UTC).toDate();
-} catch (IllegalArgumentException e) {
+ TemporalAccessor parsedTemporalDate =
parser.parseBest(srcStringVal, OffsetDateTime::from,
--- End diff --
IMO we should strive for better performance in URPs.
I had a look at your patch, and used it as a building block to make another
parsing method.
Perhaps we should have a more universal parsing method in a more global
scope to avoid code duplication.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207460442
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -144,15 +153,19 @@ public void init(NamedList args) {
}
Object defaultTimeZoneParam = args.remove(DEFAULT_TIME_ZONE_PARAM);
-DateTimeZone defaultTimeZone = DateTimeZone.UTC;
+ZoneId defaultTimeZone = ZoneOffset.UTC;
if (null != defaultTimeZoneParam) {
- defaultTimeZone =
DateTimeZone.forID(defaultTimeZoneParam.toString());
+ TimeZone.getTimeZone(defaultTimeZoneParam.toString());
+ defaultTimeZone = ZoneId.of(defaultTimeZoneParam.toString());
}
Collection formatsParam = args.removeConfigArgs(FORMATS_PARAM);
if (null != formatsParam) {
for (String value : formatsParam) {
-formats.put(value,
DateTimeFormat.forPattern(value).withZone(defaultTimeZone).withLocale(locale));
+DateTimeFormatter formatter = new
DateTimeFormatterBuilder().parseCaseInsensitive()
--- End diff --
It seems as if joda-time is case-insensitive by default.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207252080
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -144,15 +153,19 @@ public void init(NamedList args) {
}
Object defaultTimeZoneParam = args.remove(DEFAULT_TIME_ZONE_PARAM);
-DateTimeZone defaultTimeZone = DateTimeZone.UTC;
+ZoneId defaultTimeZone = ZoneOffset.UTC;
if (null != defaultTimeZoneParam) {
- defaultTimeZone =
DateTimeZone.forID(defaultTimeZoneParam.toString());
+ TimeZone.getTimeZone(defaultTimeZoneParam.toString());
+ defaultTimeZone = ZoneId.of(defaultTimeZoneParam.toString());
}
Collection formatsParam = args.removeConfigArgs(FORMATS_PARAM);
if (null != formatsParam) {
for (String value : formatsParam) {
-formats.put(value,
DateTimeFormat.forPattern(value).withZone(defaultTimeZone).withLocale(locale));
+DateTimeFormatter formatter = new
DateTimeFormatterBuilder().parseCaseInsensitive()
--- End diff --
I will have another look at the joda time defaults to double check
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/428#discussion_r207251678 --- Diff: solr/core/src/test-files/solr/collection1/conf/solrconfig-parsing-update-processor-chains.xml --- @@ -29,43 +29,43 @@ - -MM-dd'T'HH:mm:ss.SSSZ --- End diff -- Yes sadly there is no backwards compatibility between the two. For example a single Z and 5 Z in the format have a different meaning. This is all explained here: https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/428#discussion_r207052167 --- Diff: solr/core/src/test-files/solr/collection1/conf/solrconfig-parsing-update-processor-chains.xml --- @@ -29,43 +29,43 @@ - -MM-dd'T'HH:mm:ss.SSSZ --- End diff -- Can you explain why you made this and other changes in this file? If the format is compatible (joda -> java.text) then no changes would be necessary here. But if there's a backwards incompatibility here then, alas, we'll need to let users know about... --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207048145
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -144,15 +153,19 @@ public void init(NamedList args) {
}
Object defaultTimeZoneParam = args.remove(DEFAULT_TIME_ZONE_PARAM);
-DateTimeZone defaultTimeZone = DateTimeZone.UTC;
+ZoneId defaultTimeZone = ZoneOffset.UTC;
if (null != defaultTimeZoneParam) {
- defaultTimeZone =
DateTimeZone.forID(defaultTimeZoneParam.toString());
+ TimeZone.getTimeZone(defaultTimeZoneParam.toString());
--- End diff --
This line seems to be needless, since you do nothing with the response?
And it's the obsolete TimeZone class (we want ZoneId).
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207049175
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -144,15 +153,19 @@ public void init(NamedList args) {
}
Object defaultTimeZoneParam = args.remove(DEFAULT_TIME_ZONE_PARAM);
-DateTimeZone defaultTimeZone = DateTimeZone.UTC;
+ZoneId defaultTimeZone = ZoneOffset.UTC;
if (null != defaultTimeZoneParam) {
- defaultTimeZone =
DateTimeZone.forID(defaultTimeZoneParam.toString());
+ TimeZone.getTimeZone(defaultTimeZoneParam.toString());
+ defaultTimeZone = ZoneId.of(defaultTimeZoneParam.toString());
}
Collection formatsParam = args.removeConfigArgs(FORMATS_PARAM);
if (null != formatsParam) {
for (String value : formatsParam) {
-formats.put(value,
DateTimeFormat.forPattern(value).withZone(defaultTimeZone).withLocale(locale));
+DateTimeFormatter formatter = new
DateTimeFormatterBuilder().parseCaseInsensitive()
--- End diff --
it'd be nice if case insensitivity & leniency could somehow be configured
in the pattern (which it can't AFAIK), or failing that then new options to set
these things on all patterns conditionally (similar to how we have a default
time zone). But that need not be addressed now; it can be added in SOLR-12591.
Did you attempt feature parity here (thus presumably Joda was by default case
insensitive, and leniency=false)?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207051620
--- Diff:
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
---
@@ -115,9 +123,10 @@ protected Object mutateValue(Object srcVal) {
for (Map.Entry format :
formats.entrySet()) {
DateTimeFormatter parser = format.getValue();
try {
- DateTime dateTime = parser.parseDateTime(srcStringVal);
- return dateTime.withZone(DateTimeZone.UTC).toDate();
-} catch (IllegalArgumentException e) {
+ TemporalAccessor parsedTemporalDate =
parser.parseBest(srcStringVal, OffsetDateTime::from,
--- End diff --
Shouldn't this be ordered most specific to least specific? Thus Instant
comes first.
Or alternatively, parse to get a temporal accessor, then query to see what
elements of the time are there and not there and build an Instant accordingly.
My most recent patch in https://issues.apache.org/jira/browse/SOLR-12561 shows
this approach. I think this is more efficient since internally there is no
exception. Though perhaps it's less obvious / understandable. Shrug; I wonder
what you think.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207060505
--- Diff: solr/core/src/java/org/apache/solr/core/ConfigSetService.java ---
@@ -212,12 +213,12 @@ public SchemaCaching(SolrResourceLoader loader, Path
configSetBase) {
super(loader, configSetBase);
}
-public static final DateTimeFormatter cacheKeyFormatter =
DateTimeFormat.forPattern("MMddHHmmss");
+public static final DateTimeFormatter cacheKeyFormatter =
DateTimeFormatter.ofPattern("MMddHHmmss");
public static String cacheName(Path schemaFile) throws IOException {
long lastModified = Files.getLastModifiedTime(schemaFile).toMillis();
return String.format(Locale.ROOT, "%s:%s",
-schemaFile.toString(),
cacheKeyFormatter.print(lastModified));
+schemaFile.toString(),
Instant.ofEpochMilli(lastModified).atZone(ZoneId.systemDefault()).format(cacheKeyFormatter));
--- End diff --
I just switched the zoneoffset to UTC
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user barrotsteindev commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207019625
--- Diff: solr/core/src/java/org/apache/solr/core/ConfigSetService.java ---
@@ -212,12 +213,12 @@ public SchemaCaching(SolrResourceLoader loader, Path
configSetBase) {
super(loader, configSetBase);
}
-public static final DateTimeFormatter cacheKeyFormatter =
DateTimeFormat.forPattern("MMddHHmmss");
+public static final DateTimeFormatter cacheKeyFormatter =
DateTimeFormatter.ofPattern("MMddHHmmss");
public static String cacheName(Path schemaFile) throws IOException {
long lastModified = Files.getLastModifiedTime(schemaFile).toMillis();
return String.format(Locale.ROOT, "%s:%s",
-schemaFile.toString(),
cacheKeyFormatter.print(lastModified));
+schemaFile.toString(),
Instant.ofEpochMilli(lastModified).atZone(ZoneId.systemDefault()).format(cacheKeyFormatter));
--- End diff --
Sure thing,
I'll fix it ASAP.
Um I think this was my mistake I simply overlooked that. Shouldn't cause
any problems, as long as the addschema test passes
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/428#discussion_r207018765
--- Diff: solr/core/src/java/org/apache/solr/core/ConfigSetService.java ---
@@ -212,12 +213,12 @@ public SchemaCaching(SolrResourceLoader loader, Path
configSetBase) {
super(loader, configSetBase);
}
-public static final DateTimeFormatter cacheKeyFormatter =
DateTimeFormat.forPattern("MMddHHmmss");
+public static final DateTimeFormatter cacheKeyFormatter =
DateTimeFormatter.ofPattern("MMddHHmmss");
public static String cacheName(Path schemaFile) throws IOException {
long lastModified = Files.getLastModifiedTime(schemaFile).toMillis();
return String.format(Locale.ROOT, "%s:%s",
-schemaFile.toString(),
cacheKeyFormatter.print(lastModified));
+schemaFile.toString(),
Instant.ofEpochMilli(lastModified).atZone(ZoneId.systemDefault()).format(cacheKeyFormatter));
--- End diff --
I don't think we should be using the system default time zone. Is that
what it was doing? Any ramifications you can think of by simply switching to
UTC here?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....
GitHub user barrotsteindev opened a pull request: https://github.com/apache/lucene-solr/pull/428 SOLR-12586: deprecate joda-time and use java.time instead You can merge this pull request into a Git repository by running: $ git pull https://github.com/barrotsteindev/lucene-solr SOLR-12586-deprecata-joda.time Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/428.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #428 commit 6a76afa38ddf64d3517286b2c33eec3317cff004 Author: Bar Rotstein Date: 2018-08-01T17:35:11Z SOLR-12586: ParsingFieldUpdateProcessor use java.time instead of joda-time commit 6b9f2c9e033129fed6fa4b5072a15f66992511db Author: Bar Rotstein Date: 2018-08-01T17:39:16Z SOLR-12586: ConfigSetService use java.time instead of joda-time commit 7a036f7c3187c1219d0cce288ff629981b6d8479 Author: Bar Rotstein Date: 2018-08-01T17:39:51Z SOLR-12586: remove joda-time from ant dependencies and licenses --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
