[bcalles]

Hi,

Is it possibly to apply Date Created without Time Created?, if I left the Time Created field blank, I end op with the following string 2007-08-26T00:00. I would like to eliminate the T00:00 part.

br,
Bo

[DavidB]

Are you concerned about what data is being recorded, or how to use that data in an IPTC field?

If you are concerned about what is being recorded, I recommend that you save a standard set of IPTC data, to be used as your starting point for each download. If you click the '>' button next to the 'Date created' field on the 'Origin' tab, this will place tokens which will reproduce the EXIF time and date in the corresponding IPTC fields, and that can be part of your saved set. All you then have to do is make sure that the date and time remain correctly set in the camera, so that the EXIF date and time are themselves correctly set.

If you want to refer to the date (less the time) in another IPTC field, or in a directory or file name, {Y}-{m}-{D} will give you the image date in the format you used in your post.

Hope this helps.

[bcalles]

Hi David,

Sorry for not being precise enough, what I'm looking for was an option to only have the XMP Date Created field filed out not the Time Created. I can in DLP select to add automatic the EXIF Date Info, this adds the necessary mask {Y}{m}{D} in Date Created and {H}{M}{S}{Z} in the Time Created. Then I delete the mask in Time Created, so it's blank. But when I import my downloaded pics. in LightRoom, it shows 2007-08-26T00:00 in the Date Created field.
I would like to get rid of the T00:00 part, so the question is how to do that?

Br
Bo

[DavidB]

I see what you are trying to do, but there is a problem. Under the IPTC/XMP specification, the date and time fields must contain data in valid date/time format, and cannot be blank. DL Pro quite properly conforms to the specification.

Lightroom will also conform to the XMP specification (which was developed by Adobe), and is correctly displaying the data you have entered. BB Pro has facilities for displaying the IPTC date separately from the time in captions etc.; does the (much more expensive) Lightroom not have similar options?

[bcalles]

In Lightroom I can enter only the date part and LR accepts this, thus I was thinking that DLP maybe could do the same, so I could automate the job of entering this metadata field.

br,
Bo

[DavidB]

In Lightroom I can enter only the date part and LR accepts this, thus I was thinking that DLP maybe could do the same, so I could automate the job of entering this metadata field.
This is the standards minefield for you. The IPTC XMP Core standard states that the time component is 'optional' (hardly a real world judgement, in my view), but also says

Implementers are encouraged to provide the creation date and time from the EXIF data of a digital camera to the user for entering this date for the first time.Chris has followed this guidance in DL Pro.

Personally, I think that there are good reasons for reading the all the EXIF date time data into the IPTC. Better to see the time at which you actually took the picture than 00:00

[bcalles]

Hi David,

Thanks for the info, it seams that I will have to continue my current practice, by entering the date manual in LR. It's not a big problem, as I can mark all pics. taken on the same day and apply the date metadata in one step. But it would have been nice to do this job in an automated way :)

br,
Bo

[keff]

...have the XMP Date Created field filed out not the Time Created....

Last time I looked, there was only one field (i.e. date-time created), not the two as you suggest.

Steve

[DavidB]

Last time I looked, there was only one field (i.e. date-time created), not the two as you suggest.
It's defined in the spec. as a single field (Date Time), and it must be formatted as a date/time value (which is why an empty time component is 00:00:00 rather than just blank).

BB Pro, DL Pro and, I suspect, most other applications, split the two components for data entry purposes (even EXIFTool displays them separately).

The time component is also defined in the spec. as 'optional'.

So, logically, one field or two? I think it's two fields pretending to be one. But that's just my opinion.