TimeZone Change

[wazrob]

Kirk,
 
what is the reason you no longer include the computer TimeZone if the camera does not provide the info?
 
 • Photo Mechanic no longer writes the GMT delta for time values unless the offset is provided by the camera
 • The XMP field for photoshop:DateCreated now preserves sub seconds and GMT delta time zone when possible, and does not write out a GMT delta if it is unknown.
 
My Sony camera obviously does not include the timezone.  I therefore have to run a VBScript to add the computer timezone including DST to the XMP DateCreated of my photos after ingesting with PhotoMechanic although you provide the TimeZone to the IPTC TimeCreated.
 
The previous version added the computer timezone to the XMP DateCreated.  What was the problem with the previous version?
 
Thanks,
 
Warren

[Kirk Baker]

Warren,

what is the reason you no longer include the computer TimeZone if the camera does not provide the info?
 
 • Photo Mechanic no longer writes the GMT delta for time values unless the offset is provided by the camera
 • The XMP field for photoshop:DateCreated now preserves sub seconds and GMT delta time zone when possible, and does not write out a GMT delta if it is unknown.
 
My Sony camera obviously does not include the timezone.  I therefore have to run a VBScript to add the computer timezone including DST to the XMP DateCreated of my photos after ingesting with PhotoMechanic although you provide the TimeZone to the IPTC TimeCreated.
 
The previous version added the computer timezone to the XMP DateCreated.  What was the problem with the previous version?

Because the local computer's time zone may have nothing to do with the time zone in which the image was captured.  Having PM put the local computer's time zone information in when the camera provided no such information was considered bad form by some of our users.

-Kirk

[wazrob]

Sorry Kirk but I must respectively disagree with you.

The standard for XMP date-Time includes the Timezone.  If you are generating only a Date and a Time you are going against the XMP standards.
 
You said it is "considered bad form by some of our users to include timezone", to me it is bad form to not include timezone if the camera does not generate the timezone.

You also said that another reason it is not generated is because the "local computer's time zone may have nothing to do with the time zone in which the image was captured".  I would think that most users ingesting photos using PM would have just have taken the photos.  So to me the computer in most cases should have the correct timezone.

Do these users not having a computer timezone included when the camera has no timezone, somehow now include a timezone with their photos, or do they leave the timezone blank.  Non standard XMP date.

As you continually say we are changing from IPTC to XMP, The thing that I find most unusual is that you add the timezone to IPTC but not to XMP?

As I require the timezone to geotag my photos, I have a written a program that I run after ingesting with PM, this adds the computer timezone to my Sony photos and removes the decimal seconds from my Nikon photos, as I find it much easier to use HH:MM:SS rather than HH:MM:SS.DD

So if I had the ability within ingest to call a program after ingesting this would be an advantage.

Thanks for listening to my problems,

Warren

[Kirk Baker]

Warren,

We'll likely add a preference (or maybe just PMDebug.txt flag) to force the use of the local time zone when none is provided.  To continue the argument, read below.

The standard for XMP date-Time includes the Timezone.  If you are generating only a Date and a Time you are going against the XMP standards.

From the XMP spec:

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)
NOTE: The use of local times, using a time zone designator of +hh:mm or -hh:mm instead of
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.

From the RFC for ISO8601:

Time zones in ISO 8601 are represented as local time (with the location unspecified), as UTC, or as an offset from UTC.

If no UTC relation information is given with a time representation, the time is assumed to be in local time.

 

You said it is "considered bad form by some of our users to include timezone", to me it is bad form to not include timezone if the camera does not generate the timezone.

You also said that another reason it is not generated is because the "local computer's time zone may have nothing to do with the time zone in which the image was captured".  I would think that most users ingesting photos using PM would have just have taken the photos.  So to me the computer in most cases should have the correct timezone.

Do these users not having a computer timezone included when the camera has no timezone, somehow now include a timezone with their photos, or do they leave the timezone blank.  Non standard XMP date.

Time zone information is optional in ISO 8601, it may be omitted when its value is unknown and the local time zone is implied when the date string is interpreted.

-Kirk

[Kirk Baker]

Warren,

Please see this post: http://forums.camerabits.com/index.php?topic=9645.0

We have added a PMDebug.txt flag that will allow you to get the old behavior of using the local computer's time zone information when a camera does not provide time zone information.

-Kirk