Re: Time Issues.



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   bengt thuree com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]