Clock offset calculation is incorrect if local time is summer/daylight time.

[nirenjan]

With libx52_set_clock, the automatic clock offset calculation is incorrect if the local time is currently in daylight savings time.

E.g., my system is currently set to Pacific Daylight Time (UTC-07:00). However, standard time (Pacific Standard Time, UTC-08:00) is used instead to calculate the offset.

Testcase

Use x52cli to set the system clock to local time (when your system is in local daylight time). E.g. x52cli clock local 12hr ddmmyy. This should reset the offsets for the secondary and tertiary clocks back to GMT, which should display the issue.

With the previous example, if my primary clock shows 06:00pm, I expect the secondary and tertiary clocks to show 01:00am, but they show 02:00am instead.

Root Cause Analysis

This appears to be due to the use of the timezone variable, which, according to the manual, is set to the local standard time offset in seconds west of GMT, not the current local time offset. This means that timezone will always be 28800, regardless of whether it is currently daylight savings or not.

Workaround

Set primary clock to GMT and use offsets to set secondary and tertiary clock.

[nirenjan]

GNU libc has an extension in struct tm called tm_gmtoff. This is derived from BSD libc, but is not a standard member. Ideally, I'd want a solution that works with ISO C, but if this not possible, then using autoconf to detect and ensure that the extension is present on the target is permissible.

I'm strongly against using any additional libraries to detect the offset and want to do it within the confines of the standard library as far as possible.

Feel free to raise pull requests to address this.

[nirenjan]

I've added a test suite to the master branch, this allows you to test a fix by running make check TESTS=libx52/test_timezone.sh. The test suite uses the faketime program to fake the system clock, so that we can test the behavior of x52cli and libx52 at various points in time.