[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tlf-0.8.7 update before cqww-cw



Hi again,

Ok, I see. But then you are not actually taking the time from the hardware
clock but from the kernel/system (and that's how I think it should be).
AFAIK the hardware clock doesn't need to be on UTC time for this to work
as long as the system is set up correctly. And it should work regardles of
any daylight savings etc.

Oh, BTW, have you checked RFC868 for the time distribution protocol? It 
doesn't use the same Epoch but it's a widely supported and simple 
protocol. On the other hand it may be just as simple to use your own 
method, as you already have to have your own protocol for the data 
distribution anyway...

/Tomi

On Mon, 11 Nov 2002, Rein wrote:

> This is exactly what I do.... I use time(0) to generate the nr of seconds 
> since Epoch, and use strftime to generate the strings. The time sync protocol 
> also uses the same number.
>
> I will do some more testing after the cqww and I am sure we will come up with 
> a solution if necessary. (There is time until May nxt year hi...
> 
> Rein PA0RCT
> 
> On Sunday 10 November 2002 21:12, Tomi Manninen wrote:
> > Hi all,
> >
> > I have been watching this thread and wondering shouldn't time(2) or
> > gettimeofday(2) be just what is needed? They both should return the
> > time since Epoch, which is defined as 00:00:00 _UTC_, January 1, 1970.
> >
> > For formatting purposes one can use for example gmtime(3) and strftime(3).
> > I use these in gMFSK and so far it has worked just fine.
> >
> > Maybe I'm missing something here?
> >
> > /Tomi
> >
> > On Sun, 10 Nov 2002, Bob Nielsen wrote:
> > > That should work fine if the hardware clock is set to UTC.  It is
> > > possible, however, to set both the hardware clock and system clock to
> > > local time.  In that case, there is probably no easy way to handle the
> > > change in offset during these contests.  Running the hardware clock in
> > > UTC is certainly preferable, but I recall that Windows makes no
> > > distinction between hardware and system clocks, which may cause a
> > > problem with UTC in a dual-boot setup.
> > >
> > > Bob, N7XY
> > >
> > > On Sun, Nov 10, 2002 at 11:46:17AM +0100, Rein wrote:
> > > > Jaime,
> > > >
> > > > tlf now takes its time from the hardware clock. (Nr. of seconds after
> > > > 1st January 1970). As far as I know, this clock does not change with
> > > > summer/winter time, which means that although your PC clock will change
> > > > with the time zone and wintertime correction, tlf will continue to be
> > > > on UTC.
> > > >
> > > > The new time sync protocol works the same way. 3 times per minute the
> > > > value of the master is broadcast to the other nodes, which then take
> > > > the time independent of their own clock. This value is filtered to make
> > > > sure only valid values are looked at.
> > > >
> > > > Please tell me if it does not work :-)
> > > >
> > > > Rein PA0RCT
> > > >
> > > > On Sunday 10 November 2002 08:24, Jaime Robles wrote:
> > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > Hash: SHA1
> > > > >
> > > > > El Sáb 09 Nov 2002 13:50, escribió:
> > > > > Hello Rein,
> > > > > I was reading the tlf's changelog and i read:
> > > > > ======================================
> > > > > - - added parameter TIME_OFFSET= to logcfg.dat. It enables you to use
> > > > > the computer at local time, while tlf logs in utc. Use any value
> > > > > between -23 ... 23. In PA0 the value is -1 for winter time.
> > > > > ======================================
> > > > > I think there is a problem with that...
> > > > >
> > > > > The problem is that the time is changed just the big contests'
> > > > > weekend... i mean... CQ-WW-SSB and CQ-WPX-SSB are the weekend of the
> > > > > time change so i'm afraid that using a time method like that would
> > > > > not resolve the problem as the time will be changed automatically in
> > > > > our PCs and the problem will remain
> > > > >
> > > > > :-(
> > > > >
> > > > > I think the problem would be solved using a method that prevent time
> > > > > to be changed... maybe reading time once an then every  minute (more
> > > > > or less) comparing the time.... if the time is one minute after the
> > > > > last time... there is not a problem, but if time is one hour more (or
> > > > > less)... THERE IS a problem ;-)
> > > > > Using that method tlf would avoid the need of using root privileges
> > > > > to keep system time without changes...
> > > > >
> > > > > - --
> > > > > Un saludo,
> > > > > 	Jaime Robles, EA4TV
> > > > > 	jaime@robles.nu
> > > > >
> > > > > Visita	http://www.redlibre.net - La Red Libre de todos!
> > > > > 	http://smsdx.net - El DXCluster en tu movil!
> 

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org



Reply to: