fix(asn1): preserve raw date bytes for wildcard/partial date decode

[EveGun]

Summary

This PR fixes BACnet DATE wildcard handling by preserving raw DATE fields during decode.

I initially suspected the bug was in the encoder, but investigation showed the write payload was encoded correctly.
The actual issue was in decode/normalization, where partial wildcard DATE values were being normalized through JS Date, causing readback drift/misinterpretation.

Root Cause

• Wildcard/partial DATE values (e.g. 17.*.*.*, *.*.*.Fri, 28.*.2021 -> 30.*.2032) were valid on write.
• On read, decoder/normalization converted these to JS Date semantics, which cannot represent BACnet wildcard bytes faithfully.
• This produced incorrect values when rendering/roundtripping.

Changes

• Preserve raw DATE byte components (year, month, day, wday) from decoder output.
• Avoid JS Date normalization for wildcard/partial DATE patterns.
• Ensure downstream consumers can prefer raw when reconstructing BACnet DATE patterns.

Impact

• Fixes incorrect readback of wildcard/partial DATE values.
• Restores roundtrip consistency for scheduler/calendar exception use-cases.
• No behavior change for fully specified dates.

Validation

Tested with real-device and gateway flows, including:

• Single date wildcard patterns (17.*.*.*, *.*.*.Friday, *.*.*.*)
• Date range with partial wildcards (28.*.2021 -> 30.*.2032)
• Verified write succeeds where device allows pattern
• Verified readback now matches original BACnet wildcard intent

Compatibility

Backward compatible.
No API break; change is in decode fidelity and normalization behavior.

[Copilot]

Pull request overview

This PR fixes a critical issue with BACnet DATE wildcard handling by preserving raw byte values during decode operations. The problem manifested when wildcard/partial DATE values (e.g., 17.*.*.*, *.*.*.Fri) were being incorrectly normalized through JavaScript Date semantics, causing readback drift and misinterpretation. The fix preserves the raw DATE byte components alongside the normalized Date value, ensuring roundtrip consistency for scheduler and calendar operations.

Changes:

• Added raw field to BACNetAppData interface to store original byte values
• Modified decodeDate function to preserve year/month/day/wday bytes and detect wildcard/invalid patterns
• Updated bacappDecodeData to propagate raw field for DATE types
• Added comprehensive tests validating wildcard preservation in exception schedules and effective periods

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 8 comments.

File	Description
src/lib/types.ts	Added optional raw field to BACNetAppData interface for storing original byte values
src/lib/asn1.ts	Implemented wildcard detection helpers and modified decodeDate to preserve raw bytes alongside normalized Date value; updated bacappDecodeData to propagate raw field
test/unit/service-read-property.spec.ts	Added test helper encodeRawDateParts and two comprehensive tests validating raw field preservation for partial wildcard single dates and date ranges

[EveGun]

@robertsLando I think the failing test in this PR is a flaky one and not caused by the changes in this PR. It looks similar to the intermittent failure we’ve seen before.

[robertsLando]

@EveGun I know tests are lfaky but only in this PR that tests keeps failing, maybe the changes you did made the issue more visible, could you try to check that out please?

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[EveGun]

@robertsLando I investigated this, and it looks like an existing flaky issue in test/unit/request-manager.spec.ts, not something introduced by this branch.

for i in {1..20}; do node --require esbuild-register --test test/unit/request-manager.spec.ts || break; done -> fails on a random iteration.

The failure appears to be timing related (timeouts + async promise handling), so it passes/fails depending on scheduling. I can reproduce the flakiness on both this branch and master.

Perhaps we should try to fix this in a separate branch?

[robertsLando]

Perhaps we should try to fix this in a separate branch?

Ok 👍🏼