The revision timestamp of the revision entity (the field annotated with @RevisionTimestamp) can be stored into a BIGINT column on MySQL. This allows having millisecond precision on MySQL (see http://bugs.mysql.com/bug.php?id=8523).
ValidityAuditStrategy additionally stores a revision end timestamp. The problem is that it doesn't allow using a BIGINT column for this timestamp (see ValidityAuditStrategy line 162).
This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.
For details, see http://in.relation.to/2015/10/27/great-jira-cleanup-2015/
As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.
As of MySQL 5.6.4, released Dec 20, 2011, the TIMESTAMP data-type now supports 6-digit microseconds precision. The big question is whether or not the data-type maintained in the Envers REVINFO or user-defined revision-entity table should be aligned with that maintained in each audited entity's audit history table when the REVEND_TSTMP feature is enabled.
I'll look at adding a new configuration option org.hibernate.envers.use_numeric_revend_timestamp_field_type for 6.0 that will allow you to influence the use of a long-based data type rather than the default timestamp-based data type for the revision end timestamp field.
Preparing Alpha1 release