Bug: Invalid timezone values silently accepted while valid POSIX strings are not Summary

[WillemAnchor]

When configuring the timezone via the timezone NVS key, the firmware silently accepts arbitrary or invalid strings (e.g., foobar, CET, or even the IP address 192.168.0.84). However, valid POSIX-compliant timezone strings such as:

CET-1CEST-2,M3.5.0/02,M10.5.0/03

...are not stored correctly. Instead, the key is silently erased or replaced with a blank value. This results in incorrect or missing time synchronization, especially when accurate local timestamps are required for Home Assistant or MQTT integration.
Observed behavior

Setting timezone CET-1CEST-2,M3.5.0/02,M10.5.0/03 results in the timezone key being erased (blank in nvs dump).

Setting timezone CET- or any invalid string like foobar is accepted and saved without error.

In one case, after attempting to set the timezone, the sntp_server key was unintentionally overwritten with the same string.

Until SNTP sync is successful, HA receives timestamps like 1970-01-01.

Expected behavior

Valid POSIX timezone strings should be accepted and correctly parsed.

Invalid timezone strings should not be accepted silently.

The sntp_server key should not be overwritten by timezone inputs.

Clear logging should indicate if timezone parsing fails.

Suggested fix

Validate the timezone string against the POSIX format (or document accepted alternatives).

Prevent silent failure when setting timezone.

Log any parsing errors or fallbacks explicitly.

Ensure sntp_server and timezone are handled independently.

Environment

Device: Ramses ESP (latest stable from Indalo Tech shop)

Firmware: 0.4.9

MQTT broker: LAN (Home Assistant container on Synology NAS)

Timezone: Europe/Amsterdam (should resolve to CET/CEST)

Related config in NVS:

[network]: key 'sntp_server' <str> 192.168.0.84
[network]: key 'timezone'    <str> CET-1CEST-2,M3.5.0/02,M10.5.0/03

Impact

Incorrect or missing timestamps on MQTT/Home Assistant events and logs. This causes confusion and makes automation/diagnostics difficult.

[ghoti57]

The failure store problem appears to be linked to the length of the string being stored being 32 characters or more.

timezone 1234567890123456789012345678901
stores the string value as expected

while
timezone 12345678901234567890123456789012
timezone 123456789012345678901234567890123456
both fail

GMT, WET, and IST work because they are shorter strings. CET and EET fail because they have 32 characters.
The Espressif NVS storage component does split up string values into blocks of 32 characters although I would expect there to be lots of bug reports if this was the issue here.

I can't see any obvious issue in the ramses_esp code that would restrict the length to 32.

I'll continue to look.

An observation:
This suggests to me that the majority of the people who have bought the device in The Netherlands (a lot) are just using the USB interface.