Den Må, 2007-11-19, 12:36 skrev Pat Suwalski: > Thanks for replying. Comments inline. > > Bengt Thuree wrote: >> I can see two solutions, >> 1) Do not manipulate the time in EXIF at all, at least then we know what >> we have :) No matter from which camera we import the photos. > > I think this is best. Unless there is a very good reason to modify a > file, it shouldn't be modified.
Yes I agree with this. But there are some different opinions, and I can understand the ease of having it in UTC. But as you noticed, it do create a lot of problems which a normal (as in stationary in same timezone) user never notices. >This also happs to play havoc with my > rsync backups. You do have the argument if we should touch the original file or not. The way I see it, is that the image it self is the original, and the rest is the envelope around it. I for one really want all the tags and description to part of the image which makes it much easier to back up the photos. And rsync would in this case find all the photos that have been modified and copy them as well. > >> 2) Add a timezone field to each photo. This solution is the best, but >> currently mono is not handling timezone's. (will handle it not to far >> into the future though). > > Is this really necessary? I don't know anyone who actually goes and > modifies their time in their camera when they travel. I certainly don't, > and even if I do, the time in my laptop doesn't change. Since the camera > doesn't encode the timezone, it wouldn't solve any real issue. Yes, I really think it is needed. In fact, you do have three different timezones. 1) The camera's time zone 2) The computer's time zone 3) The place where you took the photo's timezone. As long as we store the local time of the photo together with which timezone it is then all use cases would be solved, since then it is very easy to receive files from around the globe, as well as from your friends camera (from 1 hour timezone difference). Very easy to correlate things that happened at the same time in different timezones. > > I think that time management is solving a problem for a relatively small > number of cases while breaking it for many more. Really, unless photo > sharing is happening, and the two or more cameras are in different > timezones, there is no problem using the time as it is. How often does > that happen? Basically when two or more people from different timezones > meet up. And those are the cases when the user should manually go and > change the time using the time tool in f-spot. You are right, for the common user who lives and works and plays in one timezone, he would never notice anything. Apart from the fact that Nautilus would not find a lot of the photos in the YYYY/MM/DD tree structure he expects it to be found in, but in one day earlier or later. But, for the user who do travel internationally, have friends/family living in other countries, or simply move from one country to another this do cause a big problem. Also, I do travel quite extensively in my job to different timezones, and I try to always change the time on the camera to the local time, or if I do forget it, I change the time afterwards in F-Spot. Key thing is that I expect the EXIF timestamp to be a valid local timestamp. If I send a photo to my father for instance, he would not have a clue when I took the photo if the EXIF timestamp is in UTC instead of in local time. > > Further, when that person sends me a photo and I import it, the time > gets readjusted and then it really means nothing. This should not happen since there should be a timezone associated with the photo. F-Spot should ask the user which timezone this photo is in when it imports it, default would be the local timezone. > > --Pat > > I think perhaps more discussion on this topic should be done on one or more of the bugs in bugzilla? http://bugzilla.gnome.org/show_bug.cgi?id=340903 http://bugzilla.gnome.org/show_bug.cgi?id=340899 http://bugzilla.gnome.org/show_bug.cgi?id=332025 -- Bengt Thuree [EMAIL PROTECTED] _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
