[Bug]: POSIX Timezone offset incorectly on T-Echo - but correct on a Haltec v3

[OrByR]

Category

Other

Hardware

T-Echo

Firmware Version

2.3.9.0afe2d4

Description

Using the correct CST6CDT,M3.2.0,M11.1.0 time zone code on a T-Echo results in the time being off by 1hr on the device. If I change it to a wrong code of CST5CDT,M3.2.0,M11.1.0 then it shows correctly on the device. Using the correct time zone code CST6CDT,M3.2.0,M11.1.0 on a Haltec v3 shows the correct time. All devices tested on 2.3.9.0afe2d4, I also tested via both GPS and phone provided time - both were affected.

Relevant log output

No response

[todd-herbert]

I have a funny feeling that I've seen the same behavior on my devices. As far as I'm aware, the time zones are handled at a deeper layer than the Meshtastic code, using platform specific implementations of tzset(), time(), gmtime(). It seems like the version the T-Echo is built with might have an issue with the tm:tm_isdt() function?

I'm not sure what the options to correct / mitigate might be. It'd be good to hear what @caveman99 thinks of the situation; I know he's worked with these functions before and probably has much better insight here.

[caveman99]

I'm swamped right now with other things but will try to look into this later this week. TZ is indeed handled by the underlying toolchain.

[jp-bennett]

I did indeed find the problem. I just didn't realize how much trouble it would be to fix. We don't actually set the system time. It always starts at the epoch, then we add an offset. So there's no date for tzset() to use to figure out DST.

Edit: it was actually a really simple fix. Just grab the real timestamp to use to calculate the offset.