I've defined a filterdef that takes a timestamp as a parameter, but whenever I try to enable the filter, and set that parameter with a java.sql.Timestamp, Hibernate is dropping the time portion of the timestamp and only querying with the date. In my example below, the startTime and endTime columns are both timestamps in the database. Any idea what I might be doing wrong, or is this a bug? Thanks for any help.

Hibernate version: 3.1rc1

Mapping documents:
AccountVersion.java:
@Basic(temporalType = TemporalType.TIMESTAMP)
public Date getEndTime() {
...
@Basic(temporalType = TemporalType.TIMESTAMP)
public Date getStartTime() {
...

Account.java:
@FilterDef(name="effectiveDate", parameters={@ParamDef(name="asOfDate", type="timestamp")})
@OneToMany(mappedBy="continuity", cascade=CascadeType.ALL)
@Sort(type = SortType.NATURAL)
@Filter(name="effectiveDate", condition=":asOfDate BETWEEN startTime and endTime")
protected SortedSet<AccountVersion> getVersions() {
...

Code between sessionFactory.openSession() and session.close():
session.enableFilter("effectiveDate").setParameter("asOfDate",
new Timestamp(new Date().getTime()));
Account account = session.load(Account.class, accountId);
account.getVersions().size();

Name and version of the database you are using:
Tried with both Hypersonic 1.8.0.1 and Oracle 10.2.0.1.0

The generated SQL (show_sql=true):
select versions0_.ACCOUNTID as ACCOUNTID1_, versions0_.id as id1_, versions0_.id as id1_0_, versions0_.OPTLOCK as OPTLOCK1_0_, versions0_.startTime as startTime1_0_, versions0_.versionNumber as versionN4_1_0_, versions0_.endTime as endTime1_0_, versions0_.ACCOUNTNAME as ACCOUNTN6_1_0_, versions0_.status as status1_0_, versions0_.conversionTrackingCode as conversi8_1_0_, versions0_.emailAddress as emailAdd9_1_0_, versions0_.state as state1_0_, versions0_.city as city1_0_, versions0_.postalCode as postalCode1_0_, versions0_.street1 as street13_1_0_, versions0_.street2 as street14_1_0_, versions0_.latestNetworkPref as latestN15_1_0_, versions0_.paymentFrequency as payment16_1_0_, versions0_.paymentType as payment17_1_0_, versions0_.ACCOUNTID as ACCOUNTID1_0_ from ACCOUNT_VER versions0_ where '2005-12-03' BETWEEN versions0_.startTime and versions0_.endTime and versions0_.ACCOUNTID='ff80808107f25b650107f25b69fb0002'


Debug level Hibernate log excerpt:
12:41:16 DEBUG DefaultInitializeCollectionEventListener : collection not cached
12:41:16 DEBUG OneToManyLoader : Static select for one-to-many Account.versions: select versions0_.ACCOUNTID as ACCOUNTID1_, versions0_.id as id1_, versions0_.id as id1_0_, versions0_.OPTLOCK as OPTLOCK1_0_, versions0_.startTime as startTime1_0_, versions0_.versionNumber as versionN4_1_0_, versions0_.endTime as endTime1_0_, versions0_.ACCOUNTNAME as ACCOUNTN6_1_0_, versions0_.status as status1_0_, versions0_.conversionTrackingCode as conversi8_1_0_, versions0_.emailAddress as emailAdd9_1_0_, versions0_.state as state1_0_, versions0_.city as city1_0_, versions0_.postalCode as postalCode1_0_, versions0_.street1 as street13_1_0_, versions0_.street2 as street14_1_0_, versions0_.latestNetworkPref as latestN15_1_0_, versions0_.paymentFrequency as payment16_1_0_, versions0_.paymentType as payment17_1_0_, versions0_.ACCOUNTID as ACCOUNTID1_0_ from ACCOUNT_VER versions0_ where :effectiveDate.asOfDate BETWEEN versions0_.startTime and versions0_.endTime and versions0_.ACCOUNTID=?
12:41:16 DEBUG Loader : loading collection: [Account.versions#ff80808107f25b650107f25b69fb0002]
12:41:16 DEBUG AbstractBatcher : about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
12:41:16 DEBUG AbstractBatcher : select versions0_.ACCOUNTID as ACCOUNTID1_, versions0_.id as id1_, versions0_.id as id1_0_, versions0_.OPTLOCK as OPTLOCK1_0_, versions0_.startTime as startTime1_0_, versions0_.versionNumber as versionN4_1_0_, versions0_.endTime as endTime1_0_, versions0_.ACCOUNTNAME as ACCOUNTN6_1_0_, versions0_.status as status1_0_, versions0_.conversionTrackingCode as conversi8_1_0_, versions0_.emailAddress as emailAdd9_1_0_, versions0_.state as state1_0_, versions0_.city as city1_0_, versions0_.postalCode as postalCode1_0_, versions0_.street1 as street13_1_0_, versions0_.street2 as street14_1_0_, versions0_.latestNetworkPref as latestN15_1_0_, versions0_.paymentFrequency as payment16_1_0_, versions0_.paymentType as payment17_1_0_, versions0_.ACCOUNTID as ACCOUNTID1_0_ from ACCOUNT_VER versions0_ where ? BETWEEN versions0_.startTime and versions0_.endTime and versions0_.ACCOUNTID=?
12:41:16 DEBUG AbstractBatcher : preparing statement
12:41:16 DEBUG NullableType : binding '03 December 2005' to parameter: 1
12:41:16 DEBUG NullableType : binding 'ff80808107f25b650107f25b69fb0002' to parameter: 2
12:41:16 DEBUG AbstractBatcher : about to open ResultSet (open ResultSets: 0, globally: 0)
12:41:16 DEBUG Loader : result set contains (possibly empty) collection: [Account.versions#ff80808107f25b650107f25b69fb0002]

I came up with a fix. I had my @FilterDef annotation on Account's superclass, and Hibernate isn't searching superclasses for @FilterDef annotations. This is kind of shady because it seems that Hibernate couldn't find the def, so it silently took its best guess at the parameter type, but got it wrong. Not sure why it decided to use a Date instead of a Timestamp. Anyway, when I copied the @FilterDef annotation to Account, things started working. Kind of sucks to have to copy the same @FilterDef to every subclass. Shouldn't these get inherited?

Ok, a little more clarification as to what's going on here. I discovered that I had an "effectiveDate" @FilterDef on another class in the same package as Account, where the parameter type was "date". Apparently if you define more than one @FilterDef with the same name, Hibernate is just picking one at random, using it, and ignoring all the others?

I figured out that moving the @FilterDef to package-info.java works fine. I was banging my head against this for a while because I kept getting a NullPointerException from AnnotationBinder.java whenever I added a package mapping to my Hibernate config. I tracked this down to what appears to be a bug in Maven's class loader (the exception was coming from within a JUnit test.) Setting maven.junit.fork=true worked around this bug.