Ok, we nailed the time issue that jean-marie.zajac was having.
It's morning in France and we've been trading email and snippets of C code. So what I found was the mktime & time(0) code is broken. Using time(0)&gmt offset & constant from the Unix code base is fine.
So why.
1) The time server apple suggests you use for os-x in Europe is broken. ntpq -p time.euro.apple.com remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .GPS. 0 - 32 64 377 0.000 0.000 0.000 194.151.19.93 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00 17.254.0.49 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00 17.108.100.13 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00 time.apple.com. 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
(mmm some of the mac os-x squeak users over there should confirm that).
2) I don't think jean had NTP services turned on, but see (1) to understand why that didn't work when we turned it on.
3) I have my suspicions that someone/thing was grabbing time from a cmos clock, but the BSD kernel clock has drifted away, and not been managed by having ntp run. Mac Hardware as documented by the NetBSD folks a few years back keeps lousy time! That's why os-x runs an NTP daemon. This might be bogus but sure sounds good.
4) Maybe mktime is just plain broken. I guess I'll check the raw number coming out of mktime and see if it gels with expectations.