Question to XMP date/time tags - especially -xmp-dwc:eventtime

[herb]

Hello Phil,

Using Exiftool 12.01 on a Windows system I started to work with XMP date/time tags.
Looking for an example that I can also use with my user-defined structures I found an example inside -xmp-dwc:
eventdate and eventtime are defined as writable =" 'date'  which is part of the defined hash %dateTimeInfo

I have the following observations:
(1) it is not possible to enter only a time-value to -eventtime
    For -eventtime=10:09:13 I always get a warning
    Warning: Invalid date/time (use YYYY:mm:dd HH:MM:SS[.ss][+/-HH:MM|Z]) in XMP-dwc:EventTime (PrintConvInv)

(2) it is also possible to enter letters to -eventdate
    -eventdate=2020:a7:03 will become 2020:07:03 without any error or warning
    -eventdate=2020:ab:03 will become 2020:03

ad (1)
This is an error for me, because - as the tagname says - only a time-value is to be given

ad (2):
Is it also an error? - because -iptc:datecreated=2020:ab:03 gives an error message

It is totally unclear to me which "syntax-checks" are really done by ExifTool or Perl.
Or to ask vice versa: how flexible are date/time values handled?

Thanks for your comments in advance
Best regards
herb

[StarGeek]

(1) it is not possible to enter only a time-value to -eventtime
    For -eventtime=10:09:13 I always get a warning
    Warning: Invalid date/time (use YYYY:mm:dd HH:MM:SS[.ss][+/-HH:MM|Z]) in XMP-dwc:EventTime (PrintConvInv)
...
This is an error for me, because - as the tagname says - only a time-value is to be given

This does seem to be an error, as the Dublin Core entry examples give either just a time or gives two times to indicate an interval.

(2) it is also possible to enter letters to -eventdate
    -eventdate=2020:a7:03 will become 2020:07:03 without any error or warning
    -eventdate=2020:ab:03 will become 2020:03
...
Is it also an error? - because -iptc:datecreated=2020:ab:03 gives an error message

See FAQ #5, specifically the third paragraph.  The IPTC Date/TimeCreated tags seem to exceptions to this but most other time related tags are flexible as mentioned in FAQ #5.

[herb]

Hello StarGeek, hello Phil,

thanks for your comments and sorry for my late reply.

Yes you are right, how Exiftool handles "strings entered by a user" in order to create/generate a value for date/time tags is a wonderful feature.

But in the special cases of -xmp-dwc:eventdate and also -xmp-dwc:eventtime Exiftool should be enhanced/corrected:
(1) -xmp-dwc:eventdate
yes it is possible to enter a valid date-string;
but Exiftool should be enhanced and ignore the time-part of such a string

(2) -xmp-dwc:eventtime
it is not possible to enter a time-value only.
This should be corrected.

The DarwinCore standard allows to specify 2 entries for both fields (begin and end); but this is not so important compared to the above mentioned enhancements/corrections.

Thanks in advance.
Best regards
herb

[herb]

Hello StarGeek, hello Phil,

Sorry, but I have to correct my previous post:

But in the special cases of -xmp-dwc:eventdate and also -xmp-dwc:eventtime Exiftool should be enhanced/corrected:
(1) -xmp-dwc:eventdate
yes it is possible to enter a valid date-string;
but Exiftool should be enhanced and ignore the time-part of such a string
and it should allow to give an (optional) timezone value

(2) -xmp-dwc:eventtime
it is not possible to enter a time-value with (optional) timezone only

Best regards
herb

[Phil Harvey]

Hi Herb,

Thanks for the report.

Sorry for the delay in responding.

I checked the DarwinCore specification and it does seem that EventTime should allow a time-only value.  I will remove the date/time parsing restrictions from this tag.

EventDate should allow a full ISO 6501 date/time.  I don't think there is a problem here.

- Phil

[herb]

Hello Phil,

thanks for the new version 12.04 of Exiftool and thanks for a correction/enhancement of the -xmp-dwc:eventtime "problem".

I regret and I am very sorry to say, but for me this is not an "Exiftool-like" correction.

The commands in DOS box

Code Select Expand

(a) exiftool.exe "-xmp-dwc:eventtime=2020:09:08 12:00:01" test.jpg
(b) exiftool.exe -xmp-dwc:eventdate=2020a09b8 -xmp-dwc:eventtime=12a6b0 test.jpg

lead to following results

Code Select Expand

(a) Event Time                      : 2020:09:08 12:00:01
(b) Event Date                      : 2020:09:08
    Event Time                      : 12a6b0

This means:
(a) it still allows date and time
(b) all great formattings of a time string are gone and leading 0 must also be given explicitely

Please remember the correction I proposed in a private mail.
Best regards
herb

[Phil Harvey]

I removed the formatting to give this tag the flexibility needed.  In all honesty, I don't think this tag is used very often, so I don't know if it warrants the extra code necessary to reformat the time.  But I'll think about this again when I get a chance.

- Phil

[herb]

Hello Phil,

thanks that you will look again into this.

I removed the formatting to give this tag the flexibility needed.

Yes, but to allow time-values

Code Select Expand

Event Time                      : 12a6b0
is for me an error and not flexibility.

I don't think this tag is used very often, so I don't know if it warrants the extra code necessary to reformat the time

Yes I agree that this tag will not be used very often. But when it exists it should work properly.

From Perl point of view I cannot decide whether my proposed solution is a good one, but one goal was to keep all advantages of flexible and correct time formatting.
And I also tried to find a solution that uses existing code as much as possible.

Thanks in advance and
best regards
herb

[Phil Harvey]

This will have to wait until ExifTool 12.06.  I don't want it to hold up the release of 12.05.

- Phil

[herb]

Hello Phil,

thanks for the new version ExifTool 12.06 and thanks for the new code for -xmp-dwc:eventtime.

In history I read

Added back conversions for XMP-dwc EventTime that were removed in 12.04 with a patch to allow time-only values

and so it gave me hope that
- it is possible now to enter a time value only and
- this value will be formatted as it is done for EventDate, but here for a time-value only.

I was very astonished and disappointed that this it not the case.

With 12.06 we can enter a timevalue only, but this is possible because it is possible to write every string we want.
Formatting  -  e.g.: 12a9:07 to 12:09:07  -  is only done in case of a string is entered that "looks like" a date and time value
(4 digits at begin for year etc etc).

Looking into the new code (for me) more or less the same procedures are called as it was done in versions till 12.03.

I know, you don't like my proposal, but
please give a solution that allows
- to enter a time value only,
- that is properly formatted ( as done for date/time values ) and
- that does not allow to enter a "nonsense" string.

Thanks in advance
herb

[Phil Harvey]

Hi Herb,

I'm sorry.  I was confusing your request with this one for which arbitrary values were supposed to be allowed.

My fault.  I'll try again with the next release.

- Phil

[herb]

Hello Phil,

thanks for the new version 12.07 and thanks for the next step towards a proper solution.
But I still have 2 points:

(1) Why is the original solution ( to write a date and time value ) still supported?
Every string starting with 4 digit is handled as a date/time value.

(2) It is possible now to only write a time value and the formatting ( e.g. leading 0 ) is done.
But please allow to write a timezone-value (together with time-value) also.

Thanks in advance
herb

[Phil Harvey]

This is the description in the DarwinCore RDF documentation that I used when I originally added this tag to ExifTool:

It is recommended that the format described by ISO 8601:2004(E) be used. As with the date terms, there is no XML Schema datatype that includes all of the possible values allowed in ISO 8601:2004(E), so there is no generic rdf:datatype attribute that would apply to all possible instances. The XML Schema dateTime datatype (xsd:time) which is effectively a subset of ISO 8601:2004(E) may be used as an rdf:datatype attribute although it is limited to values that include hours, minutes, and seconds (e.g., 13:07:56-05:00).

I read this as indicating the a full date/time value was allowed.  In the last sentence above, when it says "although it is limited to values that include hours, minutes, and seconds", I interpret this as applying to the xsd:time datatype.  And although this datatype is limited to h/m/s, that dwc:eventTime may contain dates as well.  But you're telling me that I've interpreted this incorrectly.

From your reference, the comment for this tag is

Recommended best practice is to use a date that conforms to ISO 8601-1:2019. [emphasis added]

Which specifically mentions "date", and ISO 8601 is a date/time specification.  This conflicts somewhat with the corresponding definition:

The time or interval during which an Event occurred.

which implies it should be a time-only value, but there is no clear statement indicating that dates are not allowed, although the examples section doesn't give any examples which include a date.

- Phil

[herb]

Hello Phil,

wow ... !

I agree, I have not read all DarwinCore standards, RDF-documentation etc. so detailed than you did.
I followed more or less the examples I found e.g. on https://dwc.tdwg.org/terms/#dwc:eventTime

Code Select Expand

14:07-0600 (2:07pm in the time zone six hours earlier than UTC).
08:40:21Z (8:40:21am UTC).
13:00:00Z/15:30:00Z (the interval between 1pm UTC and 3:30pm UTC).

My interpretation is that a time-value only is possible and that this time-value may have an optional timezone-value.

As eventDate can have an optional timezone-value, it would be wonderful when for eventTime (with no date-value) also an optional timezone-value is possible.

Thanks and Best regards
herb

[Phil Harvey]

I can add support for time zones and time range (two times with optional time zones separated by a "/"), but I would like to preserve the ability to write a date/time value.  However, the best way to distinguish a date is to look for a leading 4-digit year -- is this a problem?  If so, do you have an alternative?

- Phil