Re: Time handling in F-Spot
- From: "Dotan Cohen" <dotancohen gmail com>
- To: "Bengt Thuree" <bengt thuree com>
- Cc: f-spot-list <f-spot-list gnome org>
- Subject: Re: Time handling in F-Spot
- Date: Sun, 1 Oct 2006 12:57:02 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]