[ntp:questions] Re: Arcron DCF77 ref clock driver: problem with timezone and UTC

Ronan Flood ronan at noc.ulcc.ac.uk
Tue Mar 22 13:23:33 UTC 2005


"Eric Voisard" <evoisard at MAPS.ON.ieee.org> wrote:

> In the reference clock's spec, two similar query commands are described, one
> for asking for the local time and the other one for asking for the UTC time.
> Both reply frames have same format.
> 
> It's possible that the driver only uses one of the command (that would be
> the "local time" one). Then I would ask why since UTC is available and ntp
> does is job all in UTC anyhow.
> Maybe is it for historical and compatibility reasons...

The driver (refclock_arc.c) uses the command "o" (0x6f).
DCF support was grafted onto this driver by later hands, originally
it supported only MSF, which is GMT/BST.

> > I think the flag1 fudge depends on your TIMEZONE being correctly set
> > (it uses mktime), which if you have GMT set could be confusing it.
> 
> Here's what is said about the flag1: "If set to 0 (the default), the clock
> is set to UTC time. If set to 1, the clock is set to localtime."
> 
> I interpreted this as an information for the driver (which might have to
> work with different time codes): 1 => the driver must translate to UTC the
> obtained time, 0=> the driver can work "as is" with the obtained time.

That's how I read it too.

> Though, it could be the other way round: 0=> the driver must map to UTC, 1=>
> the driver can work with time "as is".
> 
> It depend on what "clock" they're talking about, computer clock or reference
> clock. I take it the reference clock.

Yep.

> As DCF77 is in CET/CEST format, then I would say the driver has to map what
> it gets to UTC, or it has to ask for the time in UTC...

Indeed, depending on the capability of the clock to adjust its output
to UTC.  Of course one wonders why your host timezone is GMT not CET?

One approach you could try is to adjust the time1 fudge factor,
"fudge 127.127.27.1 flag1 1 time1 -3600".  This is a hack and not
the right way to solve the problem, but might work ...

If your clock needs a command other than "o" to return UTC, it would
be possible to modify the driver to send that (and expect it to be
echoed back) instead.  This could perhaps be made conditional on
fudge flag4, which the driver doesn't use otherwise.

-- 
                      Ronan Flood <R.Flood at noc.ulcc.ac.uk>
                        working for but not speaking for
             Network Services, University of London Computer Centre
     (which means: don't bother ULCC if I've said something you don't like)



More information about the questions mailing list