Re: tlf-0.8.7 update before cqww-cw
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!
Reply to: