DateTime Precision Override Configurability & EnumHelper Static Methods

[aarondglover]

Hi @davebronson

Apologies for this mega PR! I tangled up my Git commits and merged back into master too early — so this ended up as two PRs in one.

Feature 1 – DateTime Precision Configuration

This feature introduces granular control over how DateTime values are formatted in HL7 messages. You can:

1. Define a global DateTime precision for all fields.
2. Override specific fields with type-safe per-field configuration.
3. Rely on full backward compatibility — if no precision config is defined, nothing breaks.

Feature 2 – EnumHelper as Static

EnumHelper can now be used as a static utility.

• Instantiating it felt awkward since the methods are pure functions with no state.
• Making them static makes the API more idiomatic with other C# libraries.
• There’s a slight performance improvement with static methods.

Compatibility Note:

• The class still implements IEnumHelper, and the instance methods simply forward to the static ones.
• This avoids breaking changes for existing DI setups or code using new EnumHelper().
• New usage will naturally lean toward the static methods.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[davebronson]

Hi @aarondglover , thank you for this work! Please bear with me while I spend a bit of time reviewing the changes. I'll probably get to it over the coming weekend.

[davebronson]

Hi Aaron. A few items in the PR to look at, if you would.

[davebronson]

Hi @aarondglover, this is looking good. Thank you for your efforts! Do you think having both /Helpers/EnumHelper and /Helpers/EnumHelpers classes (similarly named) would be confusing? I feel that it might be. Should we keep it as-is, or choose a different class name? What do you think of EnumService, or other?

If it's changed to EnumService, that would mean it'd have to live in a Service folder and namespace.

You don't have to make any changes at the moment. I'm just looking for thoughts on the naming.

[aarondglover]

@davebronson ... the “Helper vs Helpers” pair is a little bit irksome.

Constraints: As you know I can’t rename the existing EnumHelper (that would be a breaking change). The other constraint and original reason for doing this was to be idiomatic and sympathetic to established C# norms.

Why not EnumService?

• Misleading semantics: “Service” implies orchestration, I/O, or state. This is just pure, in-memory mapping.
• DI expectations: The name suggests lifetimes, config, retries, etc.—none apply here.
• Least surprise: Callers expect latency/failure from a “service”; this is deterministic and side-effect-free.
• Architecture fit: It’s a utility concern, not an application/service layer concern.

Better names: EnumUtility, EnumHelper, or EnumCodeMap (static facade) while keeping EnumHelper for DI.

Proposal:

• Keep the existing DI/instance type: IEnumHelper + EnumHelper (no change).

• Rename the new static facade from EnumHelpers to something less confusable, e.g. EnumUtility (or EnumCodes / EnumCodeMap).

  • Purpose is purely static, stateless convenience; “Service” suggests state/workflow, which this isn’t.
  • Lives alongside /Helpers with XML docs clearly pointing DI users to IEnumHelper and static callers to EnumUtility.

This avoids a breaking rename, removes the look-alike names, and keeps intent clear:

• DI: IEnumHelper/EnumHelper
• Static: EnumUtility.EnumToCode(...)

If you prefer a specific name (EnumUtility vs EnumCodes), I’ll align.

[davebronson]

@aarondglover Either EnumUtility or EnumMaps would be a good alternative, I think, yes. I like the later, but pease go ahead and pick one (or a similar alternative) and run with it.

An additional thought I had is the choice to have the new static enum methods point at the old EnumHelper methods for their return values. If the decision to provide static methods was to make the API more idiomatic with other libraries, and to also provide a small performance improvement, I think the mapping logic should live in the new static classes. And have the old EnumHelper methods be updated to point at the new static methods for its return values. So basically the reverse of what's currently in this PR. Doing this would make the static methods slightly more performant and also make it easier to deprecate EnumHelper in the future without having to change any code. Thoughts?

[davebronson]

An example, for clarity:

namespace ClearHl7.Codes.V282.Helpers
{
    public static class EnumMaps
    {
		/// <summary>
		/// Converts the given CodeAcceptApplicationAcknowledgmentConditions enum value into its HL7 equivalent code.
		/// </summary>
		/// <param name="input">An enum value to convert.</param>
		/// <returns>A string.</returns>
        public static string EnumToCode(CodeAcceptApplicationAcknowledgmentConditions input)
        {
			return input switch
			{
				CodeAcceptApplicationAcknowledgmentConditions.Always => "AL",
				CodeAcceptApplicationAcknowledgmentConditions.ErrorRejectConditionsOnly => "ER",
				CodeAcceptApplicationAcknowledgmentConditions.Never => "NE",
				CodeAcceptApplicationAcknowledgmentConditions.SuccessfulCompletionOnly => "SU",
				_ => throw new NotImplementedException()
			};
		}
		
		// [...]
}


namespace ClearHl7.Codes.V282.Helpers
{
    public class EnumHelper : IEnumHelper
    {
        /// <inheritdoc />
        public string EnumToCode(CodeAcceptApplicationAcknowledgmentConditions input)
			=> EnumMaps.EnumToCode(input);

		// [...]
	}
}