This is admittedly a fringe case. Most users who choose the date view are feeding it images that have camera dates in them. But if the objects don't have camera dates, the view is sometimes picking up the date the object was added to the project, rather than the file creation or modified date.

And in the case of a PDF with a representing image, it gets even stranger. If the PDF has no RI, its file creation date is used, which is correct. But if it does have an RI, the date the RI was attached is being used.

In the zipped project, there is an image of an Imperial convertible, and there are two identical copies of the Lorem.pdf, one with an RI, one without. The Imperial is from 2024, the PDF is from 2021. The RI is from 2022. (I've tweaked the PDF's to make sure they have exactly the same file dates.)

In the date view, the plain PDF lands in 2021 (correct). The Imperial and the PDF with an RI land in 2025 (not correct).

Edited by: JeffTucker on 18 Nov 2025, 09:09 - attachment removed

The Date view is using the camera date, then (if not exists) the last modified date. The last modified date of an album object is however also looking at the last modified date of its ".info" property file and uses the later of the two. This is what allows jAlbum to detect if image tools have been applied for instance and then reprocess that image.

So in essence, what you think of "added date" is probably the time you attached that rep image. That in turn updated the property file.

I probably don't think its wise to modify the contract of AlbumObject.getLastModified(), but I could make the date view disregard it and just look at the last modified date of the underlying file as a backup in case the camera date is missing.

I've modified v38.1.1 (core update) to just regard the file date as a backup for missing last modified date.This applies to the date view and "order by camera date"

Great