Abstract:
Link to Brainstorm: LINK

the "created" flag must not be changed just the "last modified", maybe the sorting is wrong and it sorts by "last modified"...

if it changes the "created" flag... consider a bugreport at bugs.maemo.org instead of a brainstorm problem please.

also if the image viewer does mess up the sorting it should go to the bugtracker and not to brainstorm as this is just wrong behaviour by the viewer, you need to know which item is the newest edit but you also want to keep the date you created/took it for any file, dont you? else is just odd!

did I get it wrong? if you are just looking for the tagging stuff?! I would keep it as "last modified" as you modified it... I would like mp3taggers to set "last modified" anyway.

It does not change the created flag in the File. But the Timestamp on the File system. When you use xterm or copy the pictures back to the PC you can see the changed Date and Time of the File.

By the way. I filled in a Bug report for this first: 6956
It was my first thought tat this is not done wilful. But, it could be from a different point of view. So, this Brainstorm is the second step to report this issue.

I done it all the time the other way. So this is the reason here is now a Brainstorm to vote for.

If you're changing any bits within the contents of a file (whether that is via tagging or whatever), then I would expected the modified date of the file to change, so I think the current behaviour is correct. For example, if I was to do an incremental backup of my device based on timestamps, I would want it to include the newly tagged images.

If this upsets you, then maybe what you want is a way to add tags (and rotation info) only to a separate database, and not to alter the images themselves. I can see that for some people that might be desirable, but not for others. I guess it could be an option.

Also, it's not really a matter of "which time to change". Time stamps are handled by the file system, at least that's how things should be. I very much doubt that an application has any way of influencing which of the three possible time values are changed when you tag a file.
(Unix doesn't even know the exact "create" date of a file, only something that could probably be the create date if the file hasn't been moved or renamed.)

The other issue is what you expect to see in the image viewer when it sorts pictures "by date". As there is no create date that magically attached to the file, the image viewer could try to interpret the EFIF information... which could fail or could be wrong. (Aunt Hilda got her cam on christmas eve, didn't bother to read the manual and change setting, simply shot photos the whole evening... all tagged with 1.1.2002)

I'm afraid there won't be a solution to this. The only reasonable thing to do is to offer as many settings as possible in the application that interprets the data (the image viewer in this case), but Nokia decided for Maemo 5 that options are bad. So wait until a thrid party image viewer is available.