Improper use of system time functions and data structures

[csete]

Follow-up from issue #90

It appears that we are using struct tm with tm_mon in the range [1, 12], whereas the system uses [0, 11]. Miraculously, this works out fine, except when we use manual time control with local time in December, see calculate_time() in gtk-sat-module-tmg.c. Here we use a system function to convert local time to UTC and tm_mon=12 is interpreted as January.

We need to clean this up and we must stop using struct tm with tm_mon in the range [1, 12].

[gvanem]

I'm utterly confused about the time-presentation. AFAICS, I've setup everything to show in local-time. Yet I see (now at 13:00 local time) this Next Event of HO-68 at 04:00:

I do have a TZ=CET in my environment, but fail to see any call to tzset(). Does Glib somehow do that internally? Anyway, it can account for the 9 hour anomaly.

BTW. I see the same weird issue with struct timeval in WinPcap!? (a time-val coming from the npf.sys. driver). I'm on Win-10, 1709.

[csete]

What you observe seems related to issue #6 not this one. This issue is purely internal and has no visible effects for the user.

[csete]

Sorry, I misread your comment. I don't understand what's going on but it seems to be a more high level issue than this bug. So I recommend opening a new issue.