When parsing recurring events with VALUE=DATE (all-day events),
preserve the VALUE=DATE parameter in the DTSTART string passed to
rrule-temporal. This ensures that rrule-temporal can correctly
validate that UNTIL values have the same type as DTSTART.

Previously, date-only information was lost when building the RRULE
string, causing rrule-temporal to incorrectly assume DTSTART was
DATE-TIME and reject valid DATE-only UNTIL values with the error:
"UNTIL rule part MUST have the same value type as DTSTART"

The fix uses local date components (getFullYear, getMonth, getDate)
which is consistent with how dateOnly dates are created in the
dateParameter function using new Date(year, month, day).

Fixes issue reported in MagicMirrorOrg/MagicMirror#4016 where
Google Calendar birthday events with yearly RRULE and DATE-only
UNTIL in the past failed to parse.

Test coverage:
- Yearly recurring DATE events with UNTIL
- Monthly recurring DATE events with UNTIL
- DATE events with COUNT instead of UNTIL
- Edge case: VALUE=DATE with TZID (correctly ignores TZID)

When parsing recurring events with VALUE=DATE (all-day events),
preserve the VALUE=DATE parameter in the DTSTART string passed to
rrule-temporal. This ensures that rrule-temporal can correctly
validate that UNTIL values have the same type as DTSTART.

Previously, date-only information was lost when building the RRULE
string, causing rrule-temporal to incorrectly assume DTSTART was
DATE-TIME and reject valid DATE-only UNTIL values with the error:
"UNTIL rule part MUST have the same value type as DTSTART"

The fix uses local date components (getFullYear, getMonth, getDate)
which is consistent with how dateOnly dates are created in the
dateParameter function using new Date(year, month, day).

Fixes issue reported in MagicMirrorOrg/MagicMirror#4016 where
Google Calendar birthday events with yearly RRULE and DATE-only
UNTIL in the past failed to parse.

Test coverage:
- Yearly recurring DATE events with UNTIL
- Monthly recurring DATE events with UNTIL
- DATE events with COUNT instead of UNTIL
- Edge case: VALUE=DATE with TZID (correctly ignores TZID)

When parsing recurring events with VALUE=DATE (all-day events),
preserve the VALUE=DATE parameter in the DTSTART string passed to
rrule-temporal. This ensures that rrule-temporal can correctly
validate that UNTIL values have the same type as DTSTART.

Previously, date-only information was lost when building the RRULE
string, causing rrule-temporal to incorrectly assume DTSTART was
DATE-TIME and reject valid DATE-only UNTIL values with the error:
"UNTIL rule part MUST have the same value type as DTSTART"

The fix uses local date components (getFullYear, getMonth, getDate)
which is consistent with how dateOnly dates are created in the
dateParameter function using new Date(year, month, day).

Fixes issue reported in MagicMirrorOrg/MagicMirror#4016 where
Google Calendar birthday events with yearly RRULE and DATE-only
UNTIL in the past failed to parse.

Test coverage:
- Yearly recurring DATE events with UNTIL
- Monthly recurring DATE events with UNTIL
- DATE events with COUNT instead of UNTIL
- Edge case: VALUE=DATE with TZID (correctly ignores TZID)

This includes a new version of `node-ical` which should resolve a
calendar issue that was reported
[here](#4016 (comment))
and
[here](#4010 (comment)).

Migrates the Newsfeed module to use the centralized HTTPFetcher class
introduced in MagicMirrorOrg#4016, following the same pattern as the Calendar module.

Changes:
- Refactored NewsfeedFetcher from function constructor to ES6 class
- Replaced manual fetch() + timer handling with HTTPFetcher composition
- Uses structured error objects with translation keys
- Inherits smart retry strategies (401/403, 429, 5xx backoff)
- Inherits timeout handling (30s) and AbortController
- Removed js/module_functions.js (scheduleTimer no longer needed)
- Removed #module_functions import from package.json

This migrates the Newsfeed module to use the centralized HTTPFetcher
class (introduced in #4016), following the same pattern as the Calendar
module.

This continues the refactoring effort to centralize HTTP error handling
across all modules.

## Changes

**NewsfeedFetcher:**
- Refactored from function constructor to ES6 class (like the calendar
module in #3959)
- Replaced manual fetch() + timer handling with HTTPFetcher composition
- Uses structured error objects with translation keys
- Inherits smart retry strategies (401/403, 429, 5xx backoff)
- Inherits timeout handling (30s) and AbortController

**node_helper.js:**
- Updated error handler to use `errorInfo.translationKey`
- Simplified property access (`fetcher.url`, `fetcher.items`)

**Cleanup:**
- Removed `js/module_functions.js` (`scheduleTimer` no longer needed)
- Removed `#module_functions` import from package.json

## Related

Part of the HTTPFetcher migration effort started in #4016.
Next candidate: Weather module (client-side → server-side migration).

… HTTPFetcher (#4032)

This migrates the Weather module from client-side fetching to use the
server-side centralized HTTPFetcher (introduced in #4016), following the
same pattern as the Calendar and Newsfeed modules.

## Motivation

This brings consistent error handling and better maintainability and
completes the refactoring effort to centralize HTTP error handling
across all default modules.

Migrating to server-side providers with HTTPFetcher brings:
- **Centralized error handling**: Inherits smart retry strategies
(401/403, 429, 5xx backoff) and timeout handling (30s)
- **Consistency**: Same architecture as Calendar and Newsfeed modules
- **Security**: Possibility to hide API keys/secrets from client-side
- **Performance**: Reduced API calls in multi-client setups - one server
fetch instead of one per client
- **Enabling possible future features**: e.g. server-side caching, rate
limit monitoring, and data sharing with third-party modules

## Changes

- All 10 weather providers now use HTTPFetcher for server-side fetching
- Consistent error handling like Calendar and Newsfeed modules

## Breaking Changes

None. Existing configurations continue to work.

## Testing

To ensure proper functionality, I obtained API keys and credentials for
all providers that require them. I configured all 10 providers in a
carousel setup and tested each one individually. Screenshots for each
provider are attached below demonstrating their working state.

I even requested developer access from the Tempest/WeatherFlow team to
properly test this provider.

**Comprehensive test coverage**: A major advantage of the server-side
architecture is the ability to thoroughly test providers with unit tests
using real API response snapshots. Don't be alarmed by the many lines
added in this PR - they are primarily test files and real-data mocks
that ensure provider reliability.

## Review Notes

I know this is an enormous change - I've been working on this for quite
some time. Unfortunately, breaking it into smaller incremental PRs
wasn't feasible due to the interdependencies between providers and the
shared architecture.

Given the scope, it's nearly impossible to manually review every change.
To ensure quality, I've used both CodeRabbit and GitHub Copilot to
review the code multiple times in my fork, and both provided extensive
and valuable feedback. Most importantly, my test setup with all 10
providers working successfully is very encouraging.

## Related

Part of the HTTPFetcher migration #4016.

## Screenshots

<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-06-54"
src="https://github.com/user-attachments/assets/2139f4d2-2a9b-4e49-8d0a-e4436983ed6e"
/>
<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-07-02"
src="https://github.com/user-attachments/assets/880f7ce2-4e44-42d5-bfe4-5ce475cca7c2"
/>
<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-07-07"
src="https://github.com/user-attachments/assets/abd89933-fe03-40ab-8a7c-41ae1ff99255"
/>
<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-07-12"
src="https://github.com/user-attachments/assets/22225852-f0a9-4d33-87ab-0733ba30fad3"
/>
<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-07-17"
src="https://github.com/user-attachments/assets/7a7192a5-f237-4060-85d7-6f50b9bef5af"
/>
<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-07-22"
src="https://github.com/user-attachments/assets/df84d9f1-e531-4995-8da8-d6f2601b6a08"
/>
<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-07-27"
src="https://github.com/user-attachments/assets/4cf391ac-db43-4b52-95f4-f5eadc5ea34d"
/>
<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-07-32"
src="https://github.com/user-attachments/assets/8dd8e688-d47f-4815-87f6-7f2630f15d58"
/>
<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-07-37"
src="https://github.com/user-attachments/assets/ee84a8bc-6b35-405a-b311-88658d9268dd"
/>
<img width="1920" height="1080" alt="Ekrankopio de 2026-02-08 13-07-42"
src="https://github.com/user-attachments/assets/f941f341-453f-4d4d-a8d9-6b9158eb2681"
/>

Provider "Weather API" added later:

<img width="1910" height="1080" alt="Ekrankopio de 2026-02-15 19-39-06"
src="https://github.com/user-attachments/assets/3f0c8ba3-105c-4f90-8b2e-3a1be543d3d2"
/>