Dataset::AddOrUpdate method does not serialize the DICOM tag value of VR type DT according to the standard

[manuelsujith]

Describe the bug
fo-dicom dataset AddOrUpdate method while serializing the value for a DateTime data type, strips off the fractional seconds part. For example, the value "20070628151945.406000" when written to the file via AddOrUpdate method results in a value "20070628151945" and the end part including the . separator is stripped off (.406000)

To Reproduce

Code which does not work:

var dcmFile = DicomFile.Open(@"myFIle.dcm");
var dateTimeValue = dcmFile.Dataset.GetSingleValue<DateTime>(DicomTag.AcquisitionDateTime);
// myFIle.dcm: DICOM tag AcquisitionDateTime contains value: 20070628151945.406000

dcmFile.Dataset.AddOrUpdate(DicomTag.AcquisitionDateTime, dateTimeValue);
dcmFile.Save(@"myNewFile1.dcm");
// myNewFile1.dcm: DICOM tag AcquisitionDateTime now contains value: 20070628151945

workaround:

var dateTimeValueAsString = dateTimeValue.ToString("yyyyMMddhhmms.FFFFFF", CultureInfo.InvariantCulture);
dcmFile.Dataset.AddOrUpdate(DicomTag.AcquisitionDateTime, dateTimeValueAsString);
dcmFile.Save(@"myNewFile1.dcm");

Expected behavior
Fractional seconds part shall not be stripped off and it shall be as per the definition in the DICOM standard:

Screenshots or test DICOM files
N/A

Environment
Fellow Oak DICOM version: 5.1.1
OS: Windows
Platform: .NET 7.0

[gofal]

The DicomDateTime element, that represents the ValueRepresentation DT, has some formats defined:

fo-dicom/FO-DICOM.Core/DicomElement.cs

Lines 931 to 958 in 01f3b63

	_formats = new[]
	{
	"yyyyMMddHHmmss",
	"yyyyMMddHHmmsszzz",
	"yyyyMMddHHmmsszz",
	"yyyyMMddHHmmssz",
	"yyyyMMddHHmmss.ffffff",
	"yyyyMMddHHmmss.fffff",
	"yyyyMMddHHmmss.ffff",
	"yyyyMMddHHmmss.fff",
	"yyyyMMddHHmmss.ff",
	"yyyyMMddHHmmss.f",
	"yyyyMMddHHmm",
	"yyyyMMddHH",
	"yyyyMMdd",
	"yyyyMM",
	"yyyy",
	"yyyyMMddHHmmss.ffffffzzz",
	"yyyyMMddHHmmss.fffffzzz",
	"yyyyMMddHHmmss.ffffzzz",
	"yyyyMMddHHmmss.fffzzz",
	"yyyyMMddHHmmss.ffzzz",
	"yyyyMMddHHmmss.fzzz",
	"yyyyMMddHHmmzzz",
	"yyyyMMddHHzzz",
	"yyyy.MM.dd",
	"yyyy/MM/dd"
	};

They are used for parsing the content when reading a DicomFile.
When creating/updating a DicomTag, then the constructor just takes the first of these formats and converts the DateTime into a String which then is written into the Dataset:

fo-dicom/FO-DICOM.Core/DicomElement.cs

Line 332 in 01f3b63

: base(tag, values.Select(x => x.ToString(dateFormats[0]).Replace(":", string.Empty)).ToArray())

Simple fix would be, to reorder the array of formatstrings and move the one with the fraction of seconds to the first position. This then will always use this format.

A more sophisticated approach would be, to check if the fraction is 0 or not and then either use the format as until now or use the format with the fraction.

Would it have a downside, if fractions are always written, even if they are all 0?

[manuelsujith]

Thanks @gofal for the response. Standard per say does not talk about what to do if all the fractional parts are zero. but as you can see in my previous post, the range from 000000-999999 and they only say the suffix "." omitted if the fractional part is missing. So we could technically include zeros always and should not be an issue and that's my take.

[amoerie]

Would it have a downside, if fractions are always written, even if they are all 0?

This would make every DICOM file that fo-dicom produces n bytes bigger, unnecessarily, so if it's not too much of an effort I'd prefer the more intelligent option that only uses that format if necessary.