View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000263 | GeoSetter | Image Data | public | 2008-04-10 03:25 | 2008-04-19 04:03 |
| Reporter | xaxaxa | Assigned To | Friedemann | ||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 2.4.7 beta | ||||
| Target Version | Fixed in Version | 2.4.11 beta | |||
| Summary | 0000263: No ISO 8601 conformance in generated timestamps | ||||
| Description | Consider a photo in JPEG format fresh from a usual camera. The EXIF data does not contain any timezone information. $ exiftool -P DSCF2596.jpg -EXIF:All Make : FUJIFILM Camera Model Name : FinePix F50fd Modify Date : 2008:04:05 17:56:22 Exif Version : 0220 Create Date : 2008:04:05 17:56:22 If you eg assign a location via the map and create some XMP/IPTC meta description entries, eg a caption, and GeoSetter ("Add time zone automatically to Taken Date [..]" option disabled in "data preferences") processes this file via ExifTool, to my knowladge it's GeoSetter's task to preprocess the date and time data to ISO 8601 conforming strings. In the given situation we do not have a specific time zone information, thus the timestamp has to be interpreted as localtime. This means, that there SHOULD NOT be *any* time zone designation, but GeoSetter appends "Z" to the date/time string; "Z" means "UTC" (the "Z" is *not* a separator charactar as the "T" between date and time!), though. $ exiftool -P DSCF2596.jpg -XMP-exif:All Date/Time Original : 2008:04:05 17:56:22Z Maybe there is, as indicated, a misunderstanding concerning the "Z" character's function. Eg, in the note 0000466 (among others) of report 0000230 you write: > Wenn Du Geodaten in GeoSetter hinzufügst, wird je nach Option in den > Einstellungen keine Zeitzone hinzugefügt (z.B. 2008:03:22 11:45:48Z). > Das interpretiert Lightroom dann anscheinend leider als 2008:03:22 > 11:45:48Z+0:00 There is no "11:45:48Z+0:00", that's an invalid timestamp. It should be "11:45:48+00:00" or simply "11:45:48Z". Similary 11:22:33 in CET is "11:22:33+01:00", for example, not "11:22:33Z+01:00". (As far as I understand the spec, btw, there have to be exactly two digits for the hours component of the time zone offset: something like ['+'|'-'] ( hh[mm[ss[,s+]]] | hh:mm[:ss[,s+]] ) where »,« means »','|'.'«.) Could it be that this misconception throughout the entrie application leads to some of the reported compability issues? [Oups, we can talk in German, übrigens... ^^] | ||||
| Tags | No tags attached. | ||||
|
|
If I understand right now, it's not possible to leave out the time zone, isn't it? If no time zone is given, GeoSetter passes the date time value without "Z" like this to ExifTool: -XMP:DateTimeOriginal="2003:05:08 18:50:36" The result is <exif:DateTimeOriginal>2003-05-08T18:50:36Z</exif:DateTimeOriginal> What do you think I have to change in GeoSetter? Shouldn't it be allowed to set an empty time zone? Please help me ;-) |
|
|
A time spec without a specific time zone designator is allowed by ISO 8601 as I read it. It should be interpreted as local time of an unknown time zone, not as zulu/UTC time. RFC3339 does not seem to disagree, it rather underlines this interpretation. http://tools.ietf.org/html/rfc3339#appendix-A But I see, this is probably an ExifTool issue rather than one of GeoSetter. The situation is as you already mentioned, I regrettably have to admit. ** Source file: No timezone specified in EXIF, no XMP meta data: $ exiftool -exif:DateTimeOriginal -exif:TimeZoneOffset DSCX1234.JPG Date/Time Original : 2007:09:29 23:52:22 ** Copying timestamp to XMP gives an XMP time spec *mistakenly* involving "Z": $ exiftool -P "-xmp:DateTimeOriginal<exif:DateTimeOriginal" DSCX1234.JPG $ exiftool -xmp:DateTimeOriginal DSCX1234.JPG Date/Time Original : 2007:09:29 23:52:22Z ** But passing timestamp as a formulated string "explicitly" *not* mentioning a timezone and forcing ExifTool not to use inverse PrintConv (-n) yields the right result: $ exiftool -P -n -xmp:DateTimeOriginal="2007:09:29 23:52:22" DSCX1234.JPG $ exiftool -xmp:DateTimeOriginal DSCX1234.JPG Date/Time Original : 2007:09:29 23:52:22 I'm not sure, if a time spec missing a timezone (as valid by ISO 8601) is valid according to the XMP statutes, though. (And whether GeoSetter should mess with such a work around at all while it is probably more an ExifTool issue?) Thanks anyways. Great product, as was Exifer. :) |
|
|
I just took a look into XMP specification from Adobe (http://www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf). On bottom of page 75 there's a description of possible date values: YYYY YYYY-MM YYYY-MM-DD YYYY-MM-DDThh:mmTZD YYYY-MM-DDThh:mm:ssTZD YYYY-MM-DDThh:mm:ss.sTZD with TZD = time zone designator (Z or +hh:mm or -hh:mm) Here's also a description: http://www.w3.org/TR/NOTE-datetime So date time values are not possible without time zone and ExifTool works correctly. That's new for me too, because I didn't know the meaning of "Z" by now (thanks!). Hmm, then I have to think again about editing and saving date time values in GeoSetter. Do you have a suggestion what I have to change? |
|
|
At least I have to remove the empty time zone in the data dialog, ok? |
|
|
Hmm, you're right, there's nothing to argue about, XMP /requires/ a time zone for all its timestamps (whereas EXIF does not require one, but /may/ use one for DateTimeCreated and optionally a second for ModifiedDate). ExifTool should warn about the missing time zone rather than silently assuming UTC -- just my 2 pence. As XMP meta data forms an integral part of GeoSetter's functionallity, in my opinion it should /insist/ one way or another on a time zone applied to each timestamp. I can think of several approaches. A tz-less timestamp that will be copied into an XMP field should be interpreted more or less camera-dependent. That may or may not be location dependent. Most users probably may set the clock of their cameras to the local timezone where they happen to take pictures. Others may stick to their "homebase's" timezone. So following options may come handy in the preferences: What to do with time specifications, if no time zone specified? [_] If location known, first assume location's time zone. As last resort assume following time zone: .... (*) System default .... (_) Use following time zone: .... .... {time zone selection} In the per picture(s) data editing dialogues you could replace the blank time zone value by "default" or present a time zone implicitly added shaded. I have not thought through, how that will influence the book-keeping of "dirty-flags", ie which values have been changed... |
|
|
You probably read already [XMP-Spec, p. 71]: EXIF Dates All date/time values are stored in XMP using ISO 8601 format. This is a combined date and time, with fractional seconds, and a time zone designation. The binary EXIF values generally separate the fractional seconds. EXIF 2.1 lacks time zone information; this has been partially added in EXIF 2.2. When converting to XMP, the fractional seconds should be included. If no time zone is contained in the EXIF, convert to XMP assuming a local time. So the above proposal does meets this advice. :) |
|
|
I hope you agree that the time zone depends on the date (because of daylight saving time), don't you? For example in Germany it has to be +1:00 in January and +2:00 in August. |
|
|
Being precise, it's the offset to UTC, that's dependent on the date (as formally a (fixed) time zone /implements/ some DST rule). ;) But in XMP terms, I agree, the "time zone" part of a date/timestamp depends on its date. As you already use the zoneinfo database, getting the applicable UTC-offset for a particular location->time zone possibly does not require too much of additional work? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-04-10 03:25 | xaxaxa | New Issue | |
| 2008-04-10 20:10 | Friedemann | Status | new => assigned |
| 2008-04-10 20:10 | Friedemann | Assigned To | => Friedemann |
| 2008-04-10 22:46 | Friedemann | Note Added: 0000524 | |
| 2008-04-10 22:46 | Friedemann | Status | assigned => feedback |
| 2008-04-11 00:43 | xaxaxa | Note Added: 0000530 | |
| 2008-04-11 00:47 | xaxaxa | Note Edited: 0000530 | |
| 2008-04-11 01:04 | Friedemann | Note Added: 0000531 | |
| 2008-04-11 01:08 | Friedemann | Note Added: 0000532 | |
| 2008-04-11 02:03 | xaxaxa | Note Added: 0000533 | |
| 2008-04-11 03:06 | xaxaxa | Note Added: 0000534 | |
| 2008-04-13 18:03 | Friedemann | Note Added: 0000537 | |
| 2008-04-13 18:05 | Friedemann | Note Edited: 0000537 | |
| 2008-04-14 11:29 | xaxaxa | Note Added: 0000543 | |
| 2008-04-19 04:03 | Friedemann | Status | feedback => resolved |
| 2008-04-19 04:03 | Friedemann | Fixed in Version | => 2.4.11 beta |
| 2008-04-19 04:03 | Friedemann | Resolution | open => fixed |
