From: Per Jessen peter burden wrote:

...

Per Jessen wrote:

...

I should explain what I'm really doing here: I sscanf() the timestamp into a 'tm' struct, and I correct the year and month such that they comply with what 'tm' expects. Then I convert to a number of seconds since the epoch using mktime() and subtracting the number of seconds as specified in the offset part of the timestamp - e.g. +0200 becomes -7200 seconds. But my number of seconds always ends up being off by 3600 seconds, i.e. 3600 seconds less than it should be.

...

I wonder if this is something to do with daylight saving times settings. Your +0200 log file offset may be composed of +1 hour for your Central European time zone and +1 hour for local daylight saving time.

Yep, that is correct.

...

If, when you "hand crafted" the struct tm maybe you didn't set the tm_idst field, mktime() would apply a further 1 hour correction since daylight saving time is in force locally - see tzset(3).

True, I haven't set isdst - problem is, I would much prefer not having to find out if we've DST or not ...

Yeah, DST is a bear. I gather you're trying to generate epoch time from a timestamp that is already recorded in a log. If the DST state is not recorded in the log as part of the time stamp and the system observes DST then you' are going to have to determine it yourself . And that's for the timestamp time, not for the "current" system time, so you have to figure out if it WAS DST in the past not if it IS DST now. If you can change the system to use UTC or to record UTC in the log that might help simplify the problem.