You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(asn1): preserve raw date bytes for wildcard/partial date decode (#70)
## 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.
---------
Co-authored-by: Daniel Lando <daniel.sorridi@gmail.com>
0 commit comments