Re: Time Zone.

[Tim Retout <tim retout co uk>]

On Mon, 2008-04-28 at 17:07 +0200, Stephane Delcroix wrote:
> proper tz will mean no transformation to the image date. let me
> illustrate why we need tz support.

A less extravagant example might involve two cameras from different time
zones being imported into one database. On the other hand, I haven't
planned New Year yet...

> A few days later (I guess celebrating the new year eve twice takes at
> least 2 days to recover), you want to import your photos in f-spot.

This is going to be a problem if the camera/metadata doesn't know the
timezone in which the photos were taken. f-spot currently uses the
timezone of the computer at the time the import takes place, I would
guess? So you would have to import the Paris photos before changing your
laptop's timezone to New York time. No big deal.

> 3)proper tz support
> -pictures are ordered using the converted time to utc
> -real local time (of the picture) is stored, so the fireworks images
> will be from 12.00, whatever the location

For the "real local time" to be stored, you need to store the timezone
data (or equivalently store the UTC time as well as the local time).
This can be done in two ways, as I see it:

     1. Store it in the photos.db alone. If you ever reimport your
        photos/lose the database, you will lose f-spot's knowledge of
        the timezone the computer was in at import time.
     2. Store the timezone in the image metadata somehow (perhaps
        through abuse of GPSTimeStamp, perhaps by using XMP rather than
        EXIF).

After all that, I suppose the intention is that the GUI displays the
local time of the photos. This is an impressive amount of effort for a
fairly rare sorting issue, but hey. :)

-- 
Tim Retout <tim retout co uk>