Fix "time by azimuth" crash: Cannot read properties of undefined (reading 'latitude')

[b3nj1]

Summary

Fixes #561 and #557 — every use of "time by azimuth" (the time-inject node's schedule type, and the node editor's live preview for that field) throws:

Error "Cannot read properties of undefined (reading 'latitude')", could not evaluate pdsTimeByAzimuth.<value>

While testing this, found and fixed the same class of bug for "time by elevation" (#466).

Root cause 1: _getSunTimeByAzimuth crash (#561, #557)

_getSunTimeByAzimuth(dNow, azimuthAngle, degree, tprop, latitude, longitude) takes a degree parameter ahead of tprop, but its only caller (getPropValue()'s pdsTimeByAzimuth case) calls it as this._getSunTimeByAzimuth(dNow, parseFloat(data.value), data) — 3 arguments. That leaves tprop undefined inside the function, so tprop.latitude throws a TypeError. This has apparently been present since degree was added back in 2022, but only reached users once 3.0.1 became the first non-alpha/beta release on npm (2026-06-24), which lines up with reports of this breaking around end of June.

The fix drops the unused degree parameter and derives it from this.angleType, the same way the sibling _getSunTimeByElevation() already does — no caller needs to change.

Root cause 2: getDateOfText mangles Date input (surfaced by fixing #1)

Once the crash above is fixed, getTimeProp()'s generic fallback branch (used by pdsTimeByAzimuth, which has no dedicated branch there) still produced a wrong date: it passes the Date object returned by getPropValue() into dateTimeHelper.getDateOfText(), which round-trips any object input through String() and re-parses it — silently discarding the date portion and keeping only the time of day. getDateOfText() now returns a Date it's given as-is instead of re-stringifying it.

Root cause 3: getTimeProp generic branch mishandles pdsTimeByElevation* results (#466)

getTimeProp() has no dedicated branch for pdsTimeByElevation/pdsTimeByElevationRise/pdsTimeByElevationSet/pdsTimeByElevationNext either, so they also fall through to the generic branch. Unlike azimuth, getPropValue() returns a full ISunTimeSingle object ({value: Date, name, ts, ...}) for the Rise/Set/Next variants — passing that into getDateOfText() stringifies it to "[object Object]" and throws, reproducing #466 ("Error using inject with 'next rise time by elevation': could not evaluate pdsTimeByElevationRise"). The generic branch now unwraps res.value when it's already a valid Date, before falling back to getDateOfText().

Test plan

• Added regression tests in test/20_time-inject_spec.js:
  • "evaluate time by azimuth (regression internal error sun-position #561 / inject-enhanced: Time by azimuth: internal error time-inject:Cannot read properties of undefined (reading 'latitude') #557)" — calls getPropValue() with type: 'pdsTimeByAzimuth' exactly as the crash's stack trace shows, and asserts a correct Date is returned instead of throwing.
  • "evaluate time by elevation (pdsTimeByElevationRise/Set/Next, regression Error using inject with "next rise time by elevation": could not evaluate pdsTimeByElevationRise #466)" — calls getTimeProp() (the method that actually throws per Error using inject with "next rise time by elevation": could not evaluate pdsTimeByElevationRise #466) for each variant and asserts a valid Date is returned instead of throwing.
• Verified each new test fails with the exact reported error against the pre-fix code, and passes after the fix.
• npm run testnode — 117 passing vs. 113 on master (4 tests added by this PR), same 10 pre-existing failures as master (timezone-environment-dependent, unrelated to this change).
• npm run lint — no new warnings/errors.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UJCVNfqxyRfmyJZKAVWjCG