Preserve POS timestamp offsets and normalize transaction events to UTC #759

Problem

The ACL accepts transaction event timestamps as DateTime and carries that type through its commands and transaction processor request mapping. A DateTime does not reliably preserve the POS's original UTC offset as data moves through parsing and serialization, so the ACL cannot clearly distinguish the POS-reported local time from the canonical event instant.

Relevant locations:

• TransactionProcessorACL.DataTransferObjects/Requests/TransactionRequestMessage.cs: TransactionDateTime is DateTime.
• TransactionProcessorACL.BusinessLogic/Requests/TransactionCommands.cs: logon, sale, and reconciliation commands use DateTime.
• TransactionProcessorACL/Handlers/TransactionHandlers.cs: maps the DTO timestamp directly into those commands.
• TransactionProcessorACL.BusinessLogic/Services/TransactionProcessorACLApplicationService.cs: passes the timestamp into downstream transaction processor requests.

Desired behavior

For transaction event timestamps, require an incoming ISO 8601/RFC 3339 timestamp with an explicit offset. Derive a UTC instant for host-side processing, while preserving the POS-reported value/offset (and a separately supplied zone ID if needed for audit or local trading-day behavior). Record host receipt time independently in UTC where required. The ACL must not interpret an offset-free timestamp using the service host's local zone.

Proposed changes

• Change transaction-event timestamp DTOs and command/service parameters from DateTime to DateTimeOffset (and update downstream contracts/mapping as needed).
• Validate that transaction event timestamps include an explicit offset; reject offset-free values rather than guessing.
• Normalize the canonical event timestamp to UTC when forwarding to host-side processing, while retaining source timestamp provenance where the contract requires it.
• Keep date-only reporting filters and other non-event date/time fields separate from this change.
• Update request examples and API documentation to show timestamps with numeric offsets; document any optional POS/store zone ID separately.

Acceptance criteria

• Sale, logon, and reconciliation requests accept timestamps with an explicit offset and reject or clearly flag offset-free values.
• The instant is unchanged when an offset-aware value is normalized to UTC and forwarded.
• POS-reported local time and offset are not silently replaced with the ACL host's local time/offset.
• Contract and mapping tests cover non-UTC offsets, UTC conversion, and missing offsets.
• Any zone ID has a defined source and is retained only if needed by downstream processing or audit.