[bug] Deprecated timezone `Asia/Calcutta` causes dashboard failures

[pandafy]

Describe the bug

If the OpenWISP dashboard or API receives the timezone Asia/Calcutta (now deprecated in most Linux distributions in favor of Asia/Kolkata), it causes upstream errors with InfluxDB or other dependencies. The query fails with an error similar to:

{"error":"error parsing query:  unable to find time zone Asia/Calcutta"}

This is due to Asia/Calcutta being a legacy timezone name. Not all systems provide it, and modern distributions expect Asia/Kolkata instead.

Steps To Reproduce

1. Change the timezone in your browser (or system to Asia/Kolkata)
2. Open OpenWISP dashboard
3. The dashboard/API reports a 500 error if running on a system without the legacy Asia/Calcutta (see [bug] Time zone error (error parsing query: unable to find time zone) ansible-openwisp2#541)

Expected behavior

Normalize deprecated/legacy timezone names to their current valid names before passing to InfluxDB or other backends (Asia/Calcutta → Asia/Kolkata)

References:

• Source issue: [bug] Time zone error (error parsing query: unable to find time zone) ansible-openwisp2#541

---

Suggested resolution:
Implement timezone normalization or input validation in the application code to prevent deprecated or unknown timezones from propagating to InfluxDB. We need to find a list of deprecated timezones.

[aditya-7562]

Agreed, this should be handled in the application layer via normalization and validation before hitting InfluxDB.

The authoritative source for deprecated identifiers is the IANA tz database backward file
https://data.iana.org/time-zones/tzdb/backward

We should derive a focused mapping from there (starting with common real-world cases like Asia/Calcutta → Asia/Kolkata, US/Eastern, Europe/Kiev, POSIX-style zones, etc.) and normalize them before building InfluxDB queries.

For anything unmapped and invalid, I’d prefer to fail fast rather than passing it downstream.

Before starting implementation:

• Where would you prefer this logic to live in the codebase?

• For unknown zones, do you prefer strict rejection or a fallback (e.g. UTC)?