[ntp:questions] Re: Arcron DCF77 ref clock driver: problem with timezone and UTC
evoisard at MAPS.ON.ieee.org
Tue Mar 22 09:08:40 UTC 2005
"Ronan Flood" <ronan at noc.ulcc.ac.uk> wrote in message
news:d1mlfl$r64$1 at canard.ulcc.ac.uk...
> > The receiver's LCD display indeed shows the local time (GMT+1), but its
> > specs say that a driver can query the time in UTC. On its side, the type
> > refclock driver says that by default it queries the time in UTC (as it
> > should do anyway since ntpd only works with UTC times). And in addition
> > provides the fudge parameter "flag1" to toggle between UTC and local
> > I tried to play with this "flag1" parameter, but it makes no difference:
> > ntpd keeps complaining about this 1 hour offset. The type 27 driver
> > mistaking the local time for the UTC one...
> Does the receiver spec say how to query it for UTC? It might provide
> the same time as it displays, which you say is GMT+1, unless specially
> requested. Can you set the display to UTC/GMT? That might make it
> provide UTC to the serial line. Daylight-saving could become an added
I cannot change the display settings. Apparently it's the time as sent by
the DCF77 broadcast, and as said Helmut in the other followup, DCF77 is in
CET/CEST format, not UTC.
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...
> 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.
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.
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...
Well, anyhow, it looks there is not much I can do...
Many thanks, Eric
More information about the questions