Hi there,
we are currently testing OMERO (v. 5.5.1) and found an unexpected behaviour. For all czi files we tested, the OMERO import date is equal to the “Acquired” date. Normally, one would expect that the “Acquired” date is referring to the date the picture was taken.
Since the czi file format is widespread and well supported by bio-formats this behaviour was surprising for us. Of course the Aquisition Date entry in the czi file metadata is not lost and can be inspected in the “Acquisition Tab”. But since the date of file creation would be an ideal property for filtering or sorting data in OMERO and the “Original Metadata” in the Aquisition Tab can not be used for filtering or sorting this is a missed opportunity in our view. Especially since other Metadata are imported during czi file import. In short: is there any reason why the Acquisition date is omitted ?

In testing a couple of CZI files with OMERO 5.5.1 I am finding that the acquisition date correctly precedes the import date. However, CZI is one of these formats that is really a label for a rather large tent: the format is used to represent various data and has developed variants over the years. Could you upload a sample image for us to http://qa.openmicroscopy.org.uk/qa/upload/ or otherwise so that we can see what’s going on with your files? Which microscope system are they coming off? Do let us know if your sample image can be shared publicly or if we must keep it confidential.

Thanks @shlic, from testing the file it appears that the date is being stored in a different location for these files than we would normally expect and as such is simply being added to to the Original Metadata rather than as the Image Acquisition Date. Normally for .czi files we parse the acquisition date from Information > Image > AcquisitionDateAndTime but in this case the only date appears as Information > Document > CreationDate. I should be able to put in place a fix to also check for this value when searching for an Acquisition Date.

If I understand the follow up thread correctly, a fix would need more work than initially thought.
Would it be worth asking Zeiss developers, if there is a technical reason for introducing two different acquisition date tags? Or is it likely that they just messed up their own file format for no reason?

The CreationDate tag which we are using as a fallback for AcqusitionDate does appear to be slightly different as we have files in our sample repository with both tags present, but also some which only have CreationDate but not AcquisitionDate. The proposed fix will need to be updated slightly and reviewed carefully to ensure that the updated dates are indeed valid.