[GitHub] lucene-solr issue #438: SOLR-12593: Remove date parsing functionality from e...
Github user barrotsteindev commented on the issue: https://github.com/apache/lucene-solr/pull/438 Luckily for us the locale does not seem to cause a problem. Unfortunately, the double space before single day digit test did not pass, forcing me to change the asctime configuration to "**EEE MMM [ ]d HH:mm:ss [z ]**", which results in the test passing. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #438: SOLR-12593: Remove date parsing functionality from e...
Github user dsmiley commented on the issue: https://github.com/apache/lucene-solr/pull/438 Another little detail I see that's different is the default locale. ParseDateFieldUpdateProcessorFactory uses ROOT but ExtractDateUtils uses ENGLISH. AFAIK, such a difference would appear when parsing timezones like AKST. I could be wrong. Can we see if this is indeed a problem? Ideally a test would demonstrate if it is or not. If we do find an issue here... then we could simply always configure the locale in the configs (my preference) or we could change the internal default of `ParseDateFieldUpdateProcessorFactory` --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #438: SOLR-12593: Remove date parsing functionality from e...
Github user barrotsteindev commented on the issue: https://github.com/apache/lucene-solr/pull/438 Added test for RFC-2616 (ParsingFieldUpdateProcessorsTest#testRfc2616) :-). --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #438: SOLR-12593: Remove date parsing functionality from e...
Github user barrotsteindev commented on the issue: https://github.com/apache/lucene-solr/pull/438 > Alternatively, perhaps leave that part to me. Or take a 1st cut at it and I edit from there, which I'm likely to do any way. Either way. I read the doc file and could not come up with the right words for the job. Perhaps this part is better left for you, and I could learn from the final patch so I can do these kind of tasks next time. :) --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #438: SOLR-12593: Remove date parsing functionality from e...
Github user dsmiley commented on the issue: https://github.com/apache/lucene-solr/pull/438 Docs: `solr/solr-ref-guide/src/uploading-data-with-solr-cell-using-apache-tika.adoc` Alternatively, perhaps leave that part to me. Or take a 1st cut at it and I edit from there, which I'm likely to do any way. Either way. RE the default config: I'm concerned we're not testing the default config well. Here's what I recommend: in solrconfig-parsing-update-processor-chains.xml. I think there should be one date config that is intentionally identical to the `_default` configSet's configuration of this URP (and should have a name indicating this, like "parse-date-default-configSet"). All the other configurations of this URP in the file should have exactly one pattern and is only there to test a particular condition -- i.e. the effects of a locale or an interesting pattern or something like that. I realize this recommendation would mean stomping over a bit of the changes in a previous issue, e.g. removing `parse-date-patterns-from-extract-contrib`, but the test code should stay the same, I think, notwithstanding referring to a new/renamed parse-date processor config per test. To me, the merging of patterns in ExtractDateUtils into the default URP patterns seems distinct enough from removing ExtractDateUtils that it ought to occur in its own issue. BTW I was looking at DateTimeFormatter.RFC_1123_DATE_TIME and noticed the leading day of week is optional. We should update our pattern accordingly, and test it's optionality. It'd be nice if we had a feature like `RFC_1123_DATE_TIME` where we could refer to a well known pattern by it's well-known name and in turn get the pre-compiled instance in DateTimeFormatter. But that's not in scope here. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #438: SOLR-12593: Remove date parsing functionality from e...
Github user barrotsteindev commented on the issue: https://github.com/apache/lucene-solr/pull/438 @dsmiley , I am having trouble figuring out which parts of the ref guide I should edit, could you give me a hand as I am fairly new to this? ð Apologies, I am very new to all of this. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #438: SOLR-12593: Remove date parsing functionality from e...
Github user barrotsteindev commented on the issue: https://github.com/apache/lucene-solr/pull/438 Used the patterns from parse-date-patterns-from-extract-contrib, which seem to work just fine :). --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
