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.

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================