As the code comment says, there seems to be some subtlety in how HDF5 datatypes compare equal or not based on whether the datatype has been committed to the file and loaded or not. This seems to be a change with libhdf5 v1.12 (since prior HDF5 versions seemed to work fine), but I haven't found any clarifications in documentation about whether this is expected behavior or not.
In preparing for the HDF5 v0.14 release, we'd discovered part of this issue and were already trying to copy one of the types in the comparison, but it was an insufficient patch. As best as I can tell, the caching of datatypes means that for nested data types, there can be committed vs transient comparisons made at almost any depth, so the easiest thing to do is to just copy both loaded and reconstructed types for comparison.
As the code comment says, there seems to be some subtlety in how HDF5 datatypes compare equal or not based on whether the datatype has been committed to the file and loaded or not. This seems to be a change with libhdf5 v1.12 (since prior HDF5 versions seemed to work fine), but I haven't found any clarifications in documentation about whether this is expected behavior or not.
In preparing for the HDF5 v0.14 release, we'd discovered part of this issue and were already trying to copy one of the types in the comparison, but it was an insufficient patch. As best as I can tell, the caching of datatypes means that for nested data types, there can be committed vs transient comparisons made at almost any depth, so the easiest thing to do is to just copy both loaded and reconstructed types for comparison.
Fixes #294 and fixes #297.