Lucene 1.9.1 and timeToString() apparent incompatibility with 1.4.3

[Victor Negrin]

I recently converted from Lucene 1.4.3 to 1.9.1 and in the processed
replaced all deprecated classes with the new ones as recommended (for
forward compatibility with Lucene 2.0).
This however seems to introduce an incompatibilty when the new
timeToString() and stringToTime() classes are used. Using an index created
with 1.4.3 and searched with 1.9.1  I now receive the following errors:

java.text.ParseException: Input is not valid date string: 0ehi17c0g
    at org.apache.lucene.document.DateTools.stringToDate(DateTools.java:140)
    at org.apache.lucene.document.DateTools.stringToTime(DateTools.java:110)
    at etc.., etc..

My 1.9.1 code is

when indexing:
    long modDate = conn.getLastModified();     //the file's last modified
date
    String longDate = DateTools.timeToString(modDate,
DateTools.Resolution.MINUTE);
    indxDoc.add(new Field("longdate", longDate, Field.Store.YES,
    Field.Index.TOKENIZED));

when searching:

            Date d = new Date();
            try {
              d.setTime(stringToTime(longDate));
            } catch (ParseException e) {
              e.printStackTrace();
            }


My 1.4.3 code was:
when indexing:

String longDate = DateField.timeToString(modDate);
indxDoc.add(new Field("longdate", longDate, Field.Store.YES,
Field.Index.TOKENIZED));

when searching:

Date d = new Date();
d.setTime(org.apache.lucene.document.DateField.stringToTime(longDate));

The problem does not occur if I create and search the index with 1.9.1

I assume there is a better way to do this than the above as this
incompatibility is not documented.
I know I can always revert to the old code in order to avoid re-creating the
index, but I would prefer to find a solution that uses the latest classes
AND avoids re-creating the index, if possible.
thanks for any help,

Victor