Re: Time handling in F-Spot

["Dotan Cohen" <dotancohen gmail com>]

On 01/10/06, Bengt Thuree <bengt thuree com> wrote:
> Hi Guys,
>
> I would like to propose a better time widget/handling as an upcoming
> goal, but before that wanted to share my small thoughts and see if
> anyone have any comments.
>
> To repeat, would be great to get some feedback/discussion before 9th of
> October, just in time to be one of the next goals :)
>
> As most people are aware of, I have a problem with the current way
> F-Spot is handling times. Consider the following (extreme) scenario.
> I am living in Australia, but am send on a 6 months contract to America.
> My trip goes through Hawaii, where I spend one week taking some photos.
> As soon as I get to my destination in America, I fix the timezone on my
> laptop so it shows the correct time. I then starts to import all the
> photos from my camera. A bit later I realize that the time on my camera
> is still Australia time. So we have three different timezone to worry
> about here, and which one will F-Spot use. Right now, it will change
> (read mangle) the time to be UTC based upon the computers US time.
>
> Imagine also sending this photo to a friend who will use Windows or
> Image Viewer (Eye of Gnome) to check when the photo was taken.
>
> To handle this scenario, we need (I think) the following questions
> answered during import.
>
> 1) What is the current time where you took the photo (Photo's timezone)
> 2) What is the current time in your camera (camera's timezone)
>         (Default to same as photos timezone)
> 3) What is the current time where your computer is (computers timezone).
>         (Probably not needed)
>
> The last question can probably be assumed to be don't care, since you
> are only interested in an offset to UTC anyway.
>
> What I propose is that
>
> A) The time in the EXIF part always shows the photo's local time
>    (DateTime          : Photo was modified at this time, local time
>     DateTimeOriginal  : Photo was taken at this time, local time
>     DateTimeDigitized : Photo was scanned at this time, local time)
>
> B) The time in the XMP should always be local time with TimeZone info.
>     (xmp:CreateDate   : Photo was taken at this time, UTC time
>      xmp:ModifyDate   : Photo was modified at this time, UTC time)
>
> C) Internally the timestamp should be UTC.
>
>         Example:
>          EXIF   : DateTimeOriginal = 2004-10-23T12:00:00
>          XMP    : xmp:CreateDate   = 2004-10-23T12:00:00-06:00
>          F-Spot : sqlite           = 2004-10-23T18:00:00
>
> What is needed:
> ===============
> 1) Two extra input fields in Import gui (photo and camera timezone)
> 2) Modify (correct) change date gui
> 3) Ensure timestamp is written correctly to both EXIF and XMP (with
> timezone).
> 4) During import, if XMP timestamp exists, use it, otherwise use EXIF
> together with the extra timezone informations.
>
> Any comments on this ?
>
> /Bengt
>
> From the XMP specification:
> ---------------------------
> xmp:CreateDate Date Internal The date and time the resource was
> originally created.
>
> xmp:ModifyDate Date Internal The date and time the resource was last
> modified. NOTE: The value of this property is not necessarily the same
> as the file's system modification date because it is set before the file
> is saved.
>
> Date
>    A date-time value which is represented using a subset of ISO RFC 8601
> formatting, as described in http://www.w3.org/TR/NOTE-datetime. The
> following formats are supported:
>       YYYY
>       YYYY-MM
>       YYYY-MM-DD
>       YYYY-MM-DDThh:mmTZD
>       YYYY-MM-DDThh:mm:ssTZD
>       YYYY-MM-DDThh:mm:ss.sTZD
>       YYYY = four-digit year
>    MM = two-digit month (01=January)
>    DD = two-digit day of month (01 through 31)
>    hh = two digits of hour (00 through 23)
>    mm = two digits of minute (00 through 59)
>    ss = two digits of second (00 through 59)
>    s = one or more digits representing a decimal fraction of a second
>    TZD = time zone designator (Z or +hh:mm or -hh:mm)
>           The use of local times, using a time zone designator of +hh:mm
> or -hh:mm instead of
>    NOTE:
>           Z, is recommended to promote human understanding. For example,
> if you know a file was saved at noon on October 23 a timestamp of
> 2004-10-23T12:00:00-06:00 is understandable, while 2004-10-23T18:00:00Z
> is confusing.

I agree that this should definatly be a goal. However, I don't think
that there should be any consideration for UTC- only the local time.
If the local time is wrong (the camera was not set properly when
switching time zones) then that's what the Adjust Time dialog is for.

KISS- the average Joe is not going to understand that his 'wrong time'
is a function of UTC offset.

Dotan
http://gmail-com.com