You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lucenenet.apache.org by Paulo Ferreira <pf...@gmail.com> on 2010/03/16 05:22:06 UTC

IndexReader.LastModified giving invalid date?

Hi there,

I am moving an app over from using Lucene 2.0, to Lucene 2.9.1, and I've run
into some issues with IndexReader.LastModified.

An index which I modify with Lucene 2.0 is correctly giving me the following
'long' and formatted DateTime from IndexReader.LastModified:
  634042806373153466
  3/15/2010 8:10:37 PM

When I use Lucene 2.9.1, I get the following:
  315
  01/01/0001 12:00:00 AM

For what it's worth, in both cases the IndexReader.GetCurrentVersion method
returns the same value: 634039174881899260

Reading the contents of the index works perfectly fine using both versions
of Lucene; I can dump all the documents/fields, and perform searches, and
everything else looks fine.

Also, creating a _brand new_ index using Lucene 2.9.1 ALSO results
IndexReader.LastModified returning an invalid date, so I don't think my
problem is necessarily related to reading an old index with a newer version
of Lucene 2.9.1.  In this particular test, the LastModified 'long' value was
467 and the GetCurrentVersion() result was 63404283599391.

Anyone have any thoughts as to what I am doing wrong?  Is this expected
behaviour with the latest version?

Note that I am not trying to use this method to determine if the current
IndexReader is up to date, but rather using it for other purposes.

I've also tried using both the 'string' and 'SimpleFSDirectory' versions of
the LastModified method with the same result.

Thanks,

-Paulo

RE: IndexReader.LastModified giving invalid date?

Posted by Digy <di...@gmail.com>.
Hi Paulo,

You are right, there is a change in IndexReader.LastModified in 2.9.X
which returns file.LastWriteTime.Millisecond instead of
file.LastWriteTime.Ticks as in previous versions.

But comparing with Lucene Java, both of them are incorrect.
Since DateTime.MilliSecond returns only the millisecond component of the
date, not an offset from a predetermined date and Ticks returns number of
100-nanosecond intervals that have elapsed since 12:00:00 midnight, January
1, 0001.

It should be a value measured in milliseconds since the epoch (00:00:00 GMT,
January 1, 1970)

Can you open a JIRA issue for this.

DIGY


-----Original Message-----
From: Paulo Ferreira [mailto:pfferreira@gmail.com] 
Sent: Tuesday, March 16, 2010 6:22 AM
To: lucene-net-user@lucene.apache.org
Subject: IndexReader.LastModified giving invalid date?

Hi there,

I am moving an app over from using Lucene 2.0, to Lucene 2.9.1, and I've run
into some issues with IndexReader.LastModified.

An index which I modify with Lucene 2.0 is correctly giving me the following
'long' and formatted DateTime from IndexReader.LastModified:
  634042806373153466
  3/15/2010 8:10:37 PM

When I use Lucene 2.9.1, I get the following:
  315
  01/01/0001 12:00:00 AM

For what it's worth, in both cases the IndexReader.GetCurrentVersion method
returns the same value: 634039174881899260

Reading the contents of the index works perfectly fine using both versions
of Lucene; I can dump all the documents/fields, and perform searches, and
everything else looks fine.

Also, creating a _brand new_ index using Lucene 2.9.1 ALSO results
IndexReader.LastModified returning an invalid date, so I don't think my
problem is necessarily related to reading an old index with a newer version
of Lucene 2.9.1.  In this particular test, the LastModified 'long' value was
467 and the GetCurrentVersion() result was 63404283599391.

Anyone have any thoughts as to what I am doing wrong?  Is this expected
behaviour with the latest version?

Note that I am not trying to use this method to determine if the current
IndexReader is up to date, but rather using it for other purposes.

I've also tried using both the 'string' and 'SimpleFSDirectory' versions of
the LastModified method with the same result.

Thanks,

-Paulo