Comment 34 for bug 175191

As far I understood, developers want enforce an absolute order in the photo collection, so that photos are displayed in real shoot order (a photo taken at 1.00 PM in London would be displayed after a photo taken at 1.30 PM in Rome). Is that useful? I think it is completely not: (almost) no one travel so fast and have time to shoot photos... I think it is just the classical "linux nerd thing", like the ones that scared "normal users" for years: plainly a LACK OF COMMON SENSE. The proof is that no other photo manager (think Picasa...) does a crazy thing like this. Isn't Ubuntu Linux for human beings? Developers, anyway, are completely deaf to a critical bug standing there from 2006 (they just say "we are thinking about a good solution"; in the meantime they corrupt user data...) (<RANT>and just to mention the care they have for users base, take a look to LP #204011</RANT>).

As Delcroix himself wrote upstream (https://bugzilla.gnome.org/show_bug.cgi?id=340903#c4)

"whatever the part of the world the photo is shot, when I shoot a clock saying 'it's noon', f-spot should say 'the photo was
shot at noon'".

I guess the majority (almost all?) of users set their camera to local time, so the common sense suggests to leave things unchanged; but of course I can imagine that a nerd sets its camera to UTC... (go to supermarket, ask someone "What's UTC?", then take a photo of his face; obviously, set your camera to UTC...).

Implication in changing the code I can guess:

- corrupted photos would stay corrupted, of course;
- new photos would be correctly imported.

Possible solution to fix things:

1. delete the entire database, fix photos tags copying EXIF CreateDate to DateTimeOriginal, as suggested in comment 27 and then reimport all photos;
2. fix photos tags and then fix the database accordingly (data displayed in F-Spot are read from db, not directly from EXIF).

In both cases, likely the directory tree would become inconsistent (somehow related to LP #63393); so maybe "the best thing" would be:

1. move the entire tree
2. delete the db
3. fix tags
4. reimport all photos with copy option on
4. delete the old (moved an duplicated) tree

Yes, I know, it is quite invasive... But the more time passes, worse things will get. Simple alternative would be leave alone damages done and fix things only for future imports. There are (small?) chances of misordered photos in the "boundary time", but that would be limited to a few hours interval.