---- Reported by shotwell-maint@gnome.bugs 2011-03-05 14:23:00 -0800 ----

Original Redmine bug id: 3300
Original URL: http://redmine.yorba.org/issues/3300
Searchable id: yorba-bug-3300
Original author: Ben Hutchings
Original description:

This was previously mentioned in #1712, but it appears that that ticket was
closed after the main problem (undated photos were hard/impossible to find)
was fixed.

The camera application on my phone does not store EXIF information. However,
the file timestamps are generally meaningful and could be used as a fallback.
(Some correction may be needed for differing timezones, but Shotwell already
makes that very easy to do.)

Alternately, please add an option to the 'Adjust Date and Time' dialog to set
the timestamp in this way.

Related issues:
related to shotwell - 4166: [android] wrong date for video mp4 import
from some Samsu... (Open)
related to shotwell - 3314: Wrong recognizing of Video recoring date
(3gp) (Fixed)
related to shotwell - Feature #3093: AVHCD (.MTS) video timestamps not
recognized (Open)
related to shotwell - Feature #1212: use file time for sorting photos without
EXIF data (Open)
related to shotwell - 7681: Date and time not recognized in old jpg, goes
to 'no even... (Invalid)
related to shotwell - Feature #2836: read video metadata using GStreamer (Open)
duplicated by shotwell - 4340: Imported photos get "no event", no time
stamp (Duplicate)



---- Additional Comments From shotwell-maint@gnome.bugs 2013-09-10 12:02:00 -0700 ----

### History

####

#1

Updated by Adam Dingle over 2 years ago

  * **Subject** changed from _Use file mtime as timestamp if EXIF information missing_ to _optionally use file mtime as timestamp if EXIF information missing_

We've decided not to fall back on the file modification time automatically
when EXIF information is missing, because in many cases it will be irrelevant.
However, we could possibly do either of the following:

  * Add a Shotwell preference to use the file time when EXIF information is missing. This would be off by default.
  * Add an option to 'Adjust Date and Time' to use the modification time as you suggested.

####

#2

Updated by Jim Nelson over 2 years ago

We could special case this and use the mtime the camera's filesystem reports
if no EXIF time is available.

Optionally, we could write the mtime as the EXIF time after copying the file
to the system. However, since we store the exposure date/time in the database,
this isn't absolutely necessary.

####

#3

Updated by Adam Dingle over 2 years ago

  * **Priority** set to _High_

Jim, that sounds good. I like that solution because it would solve this user's
problem without our having to add an extra option or preference.

####

#4

Updated by Adam Dingle about 2 years ago

  * **Description** updated (diff)

Note, however, that some users would like this capability even when not
importing from a camera. See the duplicate ticket #4340.

####

#5

Updated by Jan Moren about 2 years ago

A note (better here than in the duplicate I guess): I have imported at least
one set of images with no EXIF data that did get a timestamp and sorted into
an event based on their mtime. I have no idea why or how, but I would very
much like to be able to do it consistently.

What's the DB backend for this data? MySQL?

####

#6

Updated by Clinton Rogers about 2 years ago

Hi,

We use SQLite as a backend, although, because it is easy to get the tables
into a state that causes (potentially library-threatening) problems, modifying
the db directly isn't recommended.

If you simply want to apply dates to multiple photos, you might consider using
something like ExifTool, which can operate against entire directories of
photos at a time and respects wildcards. (Finer-grained tweaking may be needed
if you want to be able to, say, sort images by hour taken on the same day, but
for rough grouping by date, this may help.)

####

#7

Updated by Jan Moren about 2 years ago

Yes, I'd have to make a backup first, and modifying the db directly is not
something I'd want to do lightly.

Fixing this by date would be plenty. Just adding EXIF-data to them is quite
easy (they're sorted into the correct year/month/date folders already by
F-spot after all), but will Shotwell pick up that they now have a valid date
and sort them accordingly? Or is there a way to trigger that once the EXIF-
data is added?

####

#8

Updated by Adam Dingle about 2 years ago

Jan,

Shotwell will not currently move a photo to a new event when its timestamp
changes - either when you change it directly inside Shotwell, or when it
changes externally as you're suggesting. See #1940, which we are hoping to
address in some way for 0.12. The only way to cause Shotwell to create new
events for these photos is to remove them from your library entirely, then
reimport them into Shotwell. (Note that trashing the photos in Shotwell is not
enough for this purpose; you must use the Remove From Library command to make
them go away completely.)

####

#9

Updated by Aaron Brubacher almost 2 years ago

I vote for having this as an option, and I think it should go for videos as
well, because that is the primary issue for me. Videos taken in my camera
"KODAK EASYSHARE C183" set the mtime correctly. For any any videos edited
afterwards, the only way that I can save the correct date to the file is by
directly modifying the mtime. All of these videos are in the no event folder
currently. Too much work to manually set the date in shotwell, and that
wouldn't change the actual file anyways.

In Windows Explorer/Live Photo Gallery, the date column automatically uses the
modification date as a backup timestamp as well.

####

#10

Updated by Jim Nelson 11 months ago

  * **Target version** set to _0.14.0_

####

#11

Updated by Jim Nelson 11 months ago

  * **Category** set to _library-mode_

####

#12

Updated by Jim Nelson 11 months ago

  * **Tracker** changed from _Feature_ to _Bug_

####

#13

Updated by Jim Nelson 11 months ago

  * **Subject** changed from _optionally use file mtime as timestamp if EXIF information missing_ to _use file mtime as timestamp if EXIF information missing_
  * **Category** changed from _library-mode_ to _import_
  * **Target version** changed from _0.14.0_ to _0.15.0_

Using the mtime on the camera seems uncontroversial and something we should
do. Using the mtime for file imports is more questionable, but it sounds like
people are saying they would rather do that than treat the photo as having no
exposure date/time at all.

Note that my interpretation of the ticket is that Shotwell records the mtime
as the exposure date/time **only** at import time. If the mtime is changed on
the filesystem later, it won't be reflected in Shotwell **unless** the EXIF
date/time is available. Also note that if metadata writing is turned on,
Shotwell will write the mtime as the exposure date/time to the file, but only
if other metadata has changed (i.e tags) -- it won't fix-up an unmodified
file.

Additionally, we don't like adding a lot of options to Shotwell's Preferences
dialog, and so I don't think this will be something people can turn off an on.
If we do this, it will happen for all imported photos. Whether we do this for
videos is a separate discussion because Shotwell (rather, GStreamer) already
has severe deficiencies providing us with metadata; see #4166, #3314, #3093,
and #2836.

I would still like to think about this and discuss with the team. There's
enough if's an exceptions in the above that I think this requires a little
more thought. Outside comments are, as always, appreciated.

We won't be able to get to this for 0.14, but we'll revisit it for 0.15.

####

#14

Updated by Jim Nelson 9 months ago

We discussed this today. We'd like to implement this but we feel that the
consequences of using mtime for imports from the native filesystem is too
problematic to do so without user consent. We'll add a Preferences field that
can turn this behavior on. Since we're past string freeze, this will have to
wait until 0.15.

####

#15

Updated by Jim Nelson 8 months ago

To handle users upgrading from a library with files with no mtime, we have
#1212 to fall back on.

####

#16

Updated by Jim Nelson 2 months ago

  * **Target version** deleted (<strike>_0.15.0_</strike>)



--- Bug imported by chaz@yorba.org 2013-11-25 21:51 UTC  ---

This bug was previously known as _bug_ 3300 at http://redmine.yorba.org/show_bug.cgi?id=3300

Unknown version " in product shotwell. 
   Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution