In my archive view, and in the DB, my pictures have the wrong date. The folders and pictures within my "Albums" directory are correct, but in the DB, I have a ton of entries that, I think, date back to an earlier upgrade of ZenPhoto. (I started with version 0.5 or something like that)

Is there any way to easily reconfigure ZenPhoto so that it just grabs the dates using the creation date of each album/photo in the filesystem?

Thanks!

The easiest way to fix this is to drop the mtime field in your images table (and maybe your albums table) then run the upgrade.php program. Note: due to a bug in the 1.1.2 upgrade program you will get an error from mySQL regarding a duplicate entry in the options table. You can ignore this error. Or you can download the nightly build and run the latest and greatest zenphoto. (At your own risk, of course.)

Nightly build is found here: http://www.zenphoto.org/files/nightly/

I did as instructed and while the mtime field was re-created as promised, it still has the wrong values.

Is the "date" column also at fault here?

It could be. For that you woud have to drop the mtime field and set the date field to NULL. You can drop the image table date field as upgrade will put it back. I don't think that it will put the album one back, though.

Okay, I figured out what's going on. Here's what came from a 'stat' on that file:

Access: 2007-12-12 14:16:26.000000000 -0800
Modify: 2006-03-23 10:44:26.000000000 -0800
Change: 2006-11-07 10:16:52.000000000 -0800

Zenphoto is identifying files by their ctime, rather than their mtime. It seems to me that mtime is a more useful time for zenphoto to use, because it represents (most likely) the actual modification date of the file. File restores, etc. can alter the ctime but usually preserve the mtime. Plus you can manually change mtime using 'touch', which makes it all the more useful if you want to keep your albums properly date-tagged.

I'd call this a bug, personally. What do you think?

Okay, an update: It looks like zenphoto is inconsistent in which date it picks up. In some parts of class-gallery and class-image, it uses mtime, and in other places it picks up ctime. I edited class-gallery.php (line 363) and class-image.php (line 61), changing 'filectime' to 'filemtime' and now everything works perfectly after dropping 'date' and 'mtime' from the images table and then running the upgrade process.

I then ran the following update to set the albums to the appropriate date for the images (so as to sort properly in the gallery):

`update albums, (select albumid, max(mtime) as mtime, max(date) as date from images group by albumid) as i

set albums.mtime = i.mtime, albums.date = i.date

where albums.id = i.albumid`

The end result is just what I wanted. Everything's dated appropriately, and the gallery sorts automatically in chronological order. Beautiful!

I guess now I need to figure out how to put these changes into the subversion repository... Any chance someone else wants to do it for me? Please?

The two values filemtime and filectime are being used for quite different purposes.

filemtime is beign used to try to detect that an image has "changed" somehow and we should refresh the database with new image information. This is why I suggested dropping the mtime field--it would cause a refresh of the db.

filectime is used as a default setting for the date field in the database. It is of course argueable if this is the correct choice, but it is a first guess. It is more likely to be the data the file was uploaded, which is an approximation for the date shot. If the image has EXIF or IPTC data that includes date information, then that is the value that will be put in the date field. The date field's intent is that it is the shooting date of the image.

So, what you are in effect doing with your change is to order your images by the date they were last touched. An interesting concept, but maybe not all that generally useful.

The SVN has some new fields you can use for sort order. Perhaps you could consider sorting your images and albums by ID. This will put them in the order they were created in the database--also a close approximation of the upload order.

Unfortunately, thanks to the "archive" view (which is a fantastic way to view your images) simple sortation isn't the only problem with having the wrong datestamp.

I think ctime is a problematic way to approximate the date of a picture's creation, as ctime is an unreliable measure of a file's creation date. It's simply a system representation of the date that the inode for the file was created.

While some operating systems (MacOS X, for example) have a separate "date created" timestamp on files that is separate from the date the particular instance of the file was created, most Unixes have no equivalent. We can only tell the date of a distinct instance of a file on a given filesystem.

In MOST cases, mtime should match ctime in the case of an uploaded file (it was last modified and created when copied from the user's camera, and again, modified and uploaded at the same time). Unless the core file is updated on the server (an odd thing to do once it's already in a photo gallery), the mtime and ctime ought never to be out of sync.

So, from a functional perspective, mtime seems more useful because it can be reliably maintained through backup and restore processes and is also user-modifiable, so users can sort their photos as they wish. And in most cases, mtime and ctime would be in sync, anyhow, so from a general usability standpoint, the gallery would work as expected.

In my case, I had to recover my files from a backup, so each was created as a new inode (on a new filesystem, for that matter), with updated ctimes. The files themselves were last modified on upload date (the restore process correctly maintained all the file metadata it could).

Of course, if EXIF data is present, none of this is an issue. Many of my files lack this information because they went through batch changes from RAW to JPEG to simplify uploading, and the program I used didn't maintain that metadata. Now I know better.

I'm going to have to agree that mtime is more reliable than ctime for approximating the date the image was taken or uploaded... unfortunately neither timestamp truly gives us what we need, but mtime will make more sense to users I think.