1212 - 1819 - DateTime Original seconds = 00 deleted

[Uwe]

Hello,

 

the value of the seconds of the DateTime Original = 00, e.g. Date/Time Original 2015:05:02 13:11:00

Then I entered a keyword and a collecion tag and saved the changes.

This is the result: Date/Time Original 2015:05:02 13:11:

Tested with a DNG file.

You got a download link with a video and the image file.

 

Regards, Uwe

[fhahn]

Hello,

 

the value of the seconds of the DateTime Original = 00, e.g. Date/Time Original 2015:05:02 13:11:00

Then I entered a keyword and a collecion tag and saved the changes.

This is the result: Date/Time Original 2015:05:02 13:11:

Tested with a DNG file.

You got a download link with a video and the image file.

 

Regards, Uwe

 

Uwe:

 

The same thing happens to JPG and TIF files also.

 

It seems to me that the problem occurs when Daminion writes a time/date stamp to Exif:ModifyDate. As long as Exif:ModifyDate has an entry, I can't get the final "00" to be written. I have tried using exiftool and the ExifToolGUI tool to write this field. When the Exif:ModifyDate field is emptied, I can then write the final "00" back.

 

If I use the ExifToolGUI tool to write a date/time stamp to the Exif:ModifyDate field, I don't seem to have a problem with the final "00" being removed.

 

Hope that makes sense.

 

Frank Hahn

[Uwe]

Hello,

if that happens,

1. enter "01" in the seconds field in the tag Creation DateTime in the Properties Panel

2. Save

3. enter "00" in the seconds field in the tag Creation DateTime in the Properties Panel

4. Save

Daminion doesn't have a problem with the missing seconds data but Geosetter doesn't work without a full DateTime Original data.

Regards, Uwe

[Uwe]

it's still an issue in build 1214

[Uwe]

it's still an issue in build 1280

[Uwe]

Hello,

 

it's still an issue in 1384

 

Regards, Uwe

[fhahn]

I have plenty of *.jpg files with the ending "00" being truncated if any are needed. I am still using the current released version of Daminion, not one of the test versions.

[Uwe]

Hello,

it's still an issue in the build 1433.

Regards, Uwe

[fhahn]

Uwe:

 

Thanks for keeping track of this.

 

Frank Hahn

[Murat]

Can't reproduce it at first attempt.

 

Could you please send me a sample file to refresh my memory. Also is a time that ends with 00 should be entered via Daminion's Properties panel or by a third party tool like ExitTool?

[Uwe]

Hi Murat,

I'll sent 2 files to you by FTP to the folder "DateTimeOriginal". The original Cr2 file and the converted DNG file. Please check it with these files.

The Import Settings are:

 

Regards, Uwe

[fhahn]

I have a lot of files from scans of negatives. I used exiftool to add the DateTimeOriginal and CreateDate fields.

 

I stamped a lot of the files with an approximate time and date. For example 1985:06:01 12:00:00 (June 01, 1985).

 

What I have seen get truncated after Daminion modifies the file are the DateTimeOriginal and CreateDate fields. Once I edit and add metadata to a file, the ending 00 gets truncated.

 

These fields should look like this:

1985:06:01 12:00:00

but look like this:

1985:06:01 12:00:

 

One thing I have noticed is that as long as Exif:ModifyDate has a time stamp, you can't add back the ending seconds (00). Once this field is empty, you can.

 

Another software program that I use to look at and modify these fields is ExifToolGui. It is a front end to exiftool.

 

Frank Hahn

[Uwe]

Hello,

any news regarding this issue?

Regards, Uwe

[Uwe]

Hello,

it's still there in build 1456.

Regards, Uwe

[odog502]

Hi, just wanted to add myself as someone interested in seeing this get fixed. I posted this issue on a different thread not realizing this thread already existed.

[Uwe]

Hello,

any news regarding this issue? It's really a problem because e.g. Geosetter doesn't work without an accurate DateTimeOriginal metadata.

Regards, Uwe

[fhahn]

I know it is a workaround but I typically add the GPS coordinates with Geosetter first before I import the files into Daminion.

 

Frank Hahn

[Paul Barrett]

I have a similar problem that may have the same root cause. For details see this post:

 

https://daminion.net/user-forum/index.php?/topic/3130-dates-dates-and-more-dates/page__pid__12536#entry12536

 

Paul Barrett

[Uwe]

Hello,

this is an issue since a long time and it's still there in the 1582 build.

Regards, Uwe

[Uwe]

Hello,

this bug is still there in build 1765.

Regards, Uwe

Update: I made a test with a scanned TIF file

1. after the scan there is no DateTime Original in the metadata of the file

2. Import by Rescan folders - still no DateTime Original in the metadata of the file but in the Properties Panel is shown the DateTime of the import

3. Enter Creation DateTime 12:00:00 in the Properties Panel and a Title tag, e.g. "test" -> DateTime Original in the metadata of the file is ok: 12:00:00

4. remove the item from catalog and delete the file from folder

5. Repeat step 2

5. Enter Creation DateTime 12:00:00 in the Properties Panel, a Title tag, e.g. "test" AND Keyword tags, e.g. "original", "scanner" -> DateTime Original in the metadata of the file is not ok: 12:00:

[Paul Barrett]

So it's almost 3 years to the day since this bug was reported. May we ask when it is going to be fixed please?

[fhahn]

There use to be information on one of the Daminion web pages about bugs being fixed within a few days or something to that affect. I'm not holding my breath on this one.

 

Frank Hahn

[Paul Barrett]

+1

 

When can we expect this to be fixed please?

 

It's a tiny bug, but creates problems orders of magnitude greater. Because of this problem, Synology Moments cannot sort the files correctly, and uses date scanned instead of Date Time Original

 

Three years seems an excessive wait for a simple fix

 

Paul

[Daria Kotilainen]

Hi guys,

 

My apologies for such tremendous delay! I will ask the guys is this is possible to fix it in the upcoming 5.9 version

 

Kind regards,

Daria

[Paul Barrett]

Hi guys,

 

My apologies for such tremendous delay! I will ask the guys is this is possible to fix it in the upcoming 5.9 version

 

Kind regards,

Daria

 

That's great news. Look forward to that.

 

A supplementary question arises. Once we know that the issue has been solved in all new date handling, how will we find and repair the broken ones please? Or will it just be a case of writing all tags to file for all images in the library? I'd like a script that could find all files with MM or SS = null. Could exiftool do that?