View Issue Details

IDProjectCategoryView StatusLast Update
0000263GeoSetterImage Datapublic2008-04-19 04:03
Reporterxaxaxa Assigned ToFriedemann  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version2.4.7 beta 
Target VersionFixed in Version2.4.11 beta 
Summary0000263: No ISO 8601 conformance in generated timestamps
DescriptionConsider 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
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... ^^]
TagsNo tags attached.



2008-04-10 22:46

administrator   ~0000524

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


What do you think I have to change in GeoSetter? Shouldn't it be allowed to set an empty time zone? Please help me ;-)


2008-04-11 00:43

reporter   ~0000530

Last edited: 2008-04-11 00:47

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.

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. :)


2008-04-11 01:04

administrator   ~0000531

I just took a look into XMP specification from Adobe ( On bottom of page 75 there's a description of possible date values:


with TZD = time zone designator (Z or +hh:mm or -hh:mm)

Here's also a description:

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?


2008-04-11 01:08

administrator   ~0000532

At least I have to remove the empty time zone in the data dialog, ok?


2008-04-11 02:03

reporter   ~0000533

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...


2008-04-11 03:06

reporter   ~0000534

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. :)


2008-04-13 18:03

administrator   ~0000537

Last edited: 2008-04-13 18:05

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.


2008-04-14 11:29

reporter   ~0000543

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?

Issue History

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