[ntp:questions] ntpq -crv gives results in local time, not UTC

Dave Hart hart at ntp.org
Thu Apr 5 18:26:47 UTC 2012

On Thu, Apr 5, 2012 at 17:30, Steve Kostecke <kostecke at ntp.org> wrote:
> On 2012-04-05, Dave Hart <hart at ntp.org> wrote:
>> Of course, neither is necessary if your local timezone is UTC to begin
>> with.  I use UTC on my Windows systems because Windows misrepresents
>> historical and future timestamps which are in the other half of the
>> year, in DST terms.
> UTC is no panacea.
> Some people are more concerned about having a usable desktop clock
> which displays the time in their local time zone than they are about
> timestamps.

I agree that my solution is fraught with cost and can imagine others
reaching different decisions.  I would much prefer if Windows were
clever enough to use the UTC offset in effect at the given time when
converting between UTC and local -- instead, it always uses the
current UTC offset essentially pretending daylight savings doesn't
exist.  Worse, applications can't work around it without rewriting the
bulk of Windows UTC/localtime conversion code, either relying on the
undocumented Windows timezone information in the registry, or using
the open source Olsen stuff and taking on keeping it up to date.

Fortunately, it's pretty easy in practice to use a Windows desktop
with UTC as the local timezone.  The system tray's clock will display
up to two additional timezones when hovered (as a tooltip) or
left-clicked (with analog clocks and the current month's calendar).
Similarly, Microsoft Outlook's calendar functionality can displaying
an alternate timezone alongside the default.  My computer's timestamps
don't match wall-clock timezone, it's true, but that's rarely an issue
for me in practice, and when it is, I can do the conversion better
than Windows.

Dave Hart

More information about the questions mailing list