Skip to content

Keep a DTM value unchanged when reading its parts (fixes #917) - #918

Open
iacsha wants to merge 1 commit into
nHapiNET:masterfrom
iacsha:fix/917-dtm-read-keeps-value
Open

iacsha wants to merge 1 commit into
nHapiNET:masterfrom
iacsha:fix/917-dtm-read-keeps-value

Conversation

@iacsha

@iacsha iacsha commented Nov 12, 2026

Copy link
Copy Markdown

Fixes #917.

Problem

Reading .Year, .Month, .Day or any other part of a DTM (or any TSComponentOne) changes its .Value when the value has no time zone. The first read builds the cached CommonTS detail, and from then on the Value getter returned the detail's value instead of the stored one. CommonTS adds the local GMT offset to a value that has none, so:

pid.DateTimeOfBirth.Value = "20100101";
var year = pid.DateTimeOfBirth.Year;
// Value is now "20100101-0500" (local offset), and GetAsDate() throws

Fix

TSComponentOne.Value now always returns the stored value, so reading a part never changes it. The methods that do change the detail write its result back to the stored value: the Offset setter, SetDatePrecision, SetDateMinutePrecision and SetDateSecondPrecision. They update Value exactly as before. Setting Value still updates the cached detail, so the parts follow a new value.

Tests

New DtmPartsTest26, using the issue's ADT^A05 / PID-7 example:

  • Reading the parts leaves Value unchanged for a date, a date-time, a date-time with seconds, and a value that already has an offset.
  • The parts and GetAsDate() still return the right values.
  • Setting Value after reading the parts updates them.
  • The precision setters still update Value.

Three of these fail on master. The full NHapi.NUnit suite passes on net8.0 (971 passed, 2 skipped) with the container set to UTC, America/New_York and Asia/Kolkata. No new StyleCop warnings.

This touches the same file as #915 (GetAsDate formats) but different lines, and the two merge cleanly.

Reading Year, Month, Day or another part of a TSComponentOne builds the
cached CommonTS detail, and the Value getter then returned the detail's
value. CommonTS adds the local GMT offset to a value that has none, so
"20100101" became "20100101-0500" and GetAsDate() then threw.

Value now always returns the stored value. The Offset setter and the
SetDatePrecision, SetDateMinutePrecision and SetDateSecondPrecision
methods write the detail's result back to it, so they still update the
value as before.

Adds DtmPartsTest26: three of its cases fail on master.
@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 4 complexity

Metric Results
Complexity 4

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Accessing Year, Month, Day on DTM object adds timezone to value (HL7 v2.6)

1 participant