AuditReader.getRevisionNumberForDate(LocalDateTime) delegates to RevisionTimestampValueResolver.resolveByValue(LocalDateTime). When the type of the revision timestamp property in our revision entity is Long/long, the argument is converted to epoch seconds here:

                return localDateTime.atZone( ZoneId.systemDefault() ).toInstant().getEpochSecond();

The result is then used as the parameter in the revision number query:

select max(rev) from revision_info where revtstmp <= ?

However, the revtstmp represents epoch millis, as can be seen a few lines up in RevisionTimestampValueResolver.resolveNow(Object):

revisionTimestampSetter.set( object, System.currentTimeMillis() );

As a result, AuditRead.getRevisionNumberForDate(LocalDateTime) will basically never return anything if we have a @RevisionTimestamp long revtstmp attribute.

Workaround: Use AuditReader.getRevisionNumberForDate(Date), where the java.util.Date argument is correctly converted to epoch millis in RevisionTimestampValueResolver.resolveByValue(Date).