Perhaps there should be an option on the Import Folder dialog to take the date
from the date of the import, the creation date, or possibly a user specified
date (for when the prior aren't accurate).

A related feature request would be to have the ability to manually specify the
photo date.

Just to add a "me too".  I tried importing a directory structure that had been
copied from another machine.  There was no exif data in the files.  I was
chagrined that despite taking care to preserve the files' mtimes, f-spot wasn't
looking at those.  So yeah, that'd make a good option.

In response to comment #1 (editing date/time info by hand), please see bug 302567.

Created attachment 50342 [details] [review]
proposed patch

Use Lookup instead of GetEntry and fall back to parent class implementation
(which will use file creation time) if the DateTimeOriginal tag does not exist.

Created attachment 50718 [details] [review]
DateTimeOriginal, DateTime, and last File creation time

Hej

I created a small patch on F-Spot-0.0.13 for Bug 170771 and 309436.

In essence what I did was as follows:

1) ExifUtils.cs
	// Check first for DateTimeOriginal, then for DateTime, 
	// and last for File Creation time of the photo.
	info.DateTime = exif_data.LookupFirstValue (Exif.Tag.DateTimeOriginal);

	if (info.DateTime == null || info.DateTime == "")
			info.DateTime = exif_data.LookupFirstValue
(Exif.Tag.DateTime);
	if (info.DateTime == null || info.DateTime == "") {
			DateTime slask = File.GetCreationTimeUtc  (path);
			info.DateTime = slask.ToString ("yyyy:MM:dd hh:mm:ss");

	}


2) InfoBox.cs
	if (photo.Time > DateTime.MinValue && photo.Time < DateTime.MaxValue)

	Modified InfoBox.cs to instead of checking exposure_info.DateTime, 
	we check photo.Time. (Do not know why we check exposure_info...)

3) JpegFile.cs
	string time_str = "";
	// Check first for DateTimeOriginal, then for DateTime, 
	// and last for File Creation time of the photo.
	time_str = ed.LookupFirstValue (Exif.Tag.DateTimeOriginal);
	if (time_str == null || time_str == "")
		time_str = ed.LookupFirstValue (Exif.Tag.DateTime);
	if (time_str == null || time_str == "") {
		DateTime slask = File.GetCreationTimeUtc  (path);
		time_str = slask.ToString ("yyyy:MM:dd hh:mm:ss");
	}

	Instead of the original routine (below)
	     //Exif.ExifContent content = ed.GetContents (Exif.Ifd.Exif);
	     // Exif.ExifEntry entry = content.GetEntry
(Exif.Tag.DateTimeOriginal);
	     // time = Exif.ExifUtil.DateTimeFromString (entry.Value);
	which always returned Now() if no Exif tags were available, I used the
same
	routine as in ExifUtils.cs which works fine. Now we check in order for
		1) DateTimeOriginal
		2) DateTime
		3) file creation date


I did not add a possibility to set a date/time manually when you add pictures.

The command I used to create the diff files were as follows
  diff -Naur ../f-spot-0.0.13.orig/src/ src/ > patch.diff

This patch will fix the problem with 170771 (no Exif data in files), as well as

309436 (EXIF value for DateTimeOriginal do not exist, but DateTime do)


/Bengt

Created attachment 50984 [details] [review]
Patch

New version of the patch.

The patch this time only checks the photo.Time for a valid time.
Patch for http://bugzilla.gnome.org/attachment.cgi?bugid=302567 will set the
photo.Time to DateTimeOriginal, DateTimeDigitized, DateTime, or File Creation
time,
as well as update the picture's DateTimeOriginal EXIF tag if needed.

Stanislav Brabec posted some good ideas in duplicate bug #317838:

"For exifless images, f-spot currently sets the time to import time. This is not
very useful.

Possible solutions:
- Use image mtime. Trivial.
- Ask user. Trivial.
- Try to search "source" image. For example: pict3123_edited.jpg will search for
pict3123.*. Complicated and maybe also slow, but can help a lot for converted
RAW images without EXIF."

*** Bug 317838 has been marked as a duplicate of this bug. ***

Bengt's patch in Comment #6 fixes pretty much all of the import problems.

Correction to Comment #9: I was referring to Comment #5.

Another vote for this bug. I have a bunch of old pictures taken with an old
digital camera which didn't write exif info. I know when they were taken and the
file date is correct (2002...), but when I import them, they all get the current
date, which mucks up my index. Merge the patch already :). thanks!

Lewing suggested on IRC I should submit a test image, so I'm attaching one. File
date is 26th February 2002, which is the date I'd like f-spot to use. There's no
EXIF data in the image.

Created attachment 53634 [details]
test image for date bug.

A couple of notes on this.
 File.GetCreationTimeUtc
1) f-spot never used the import time but it used the incorrectly named
File.GetCreationTimeUtc which on unix returns the file ctime (aka _Change_ time)
which really has more to do with the directory than the file so this often ended
up being the import time.  CVS now uses the earlier of mtime and ctime when no
exif data is present.

2) When exif data is present is present CVS currently uses DateTimeOriginal and
if it can't find that, DateTime.  This will eventually need to be changed to
look through all the possible metdata sources.  Addtionally this problem applies
to more than just jpeg files and all the various file formats should be changed
to merge the metadata and make a best guess.

3) The patch no longer applies to the info box as that code has been rewritten.
 It might still make sense to use the photo.Time for the info box the current
code does not but it would be trivial to change.

Regarding the info box: I think we should check photo.Time, since this is where
all the information about the photo/image is stored. Easier to use one routine also.

I created bug #331503 with associated patch that should fix this problem.
Maybee not needed to create a new bug, but anyway.
#331503 is about keeping the Unix file stamp on the photo when you import it.

Perhaps we can close this one, and let bug #331503 handle it?
Since F-Spot will check the timestamp of the file it self as a last resort, and bug #331503 ensures that the timestamp is equal to the original file.

yeah I'm closing this.