Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

TIME /S?

May
12,846
164
TIME /S doesn't seem to work very well. Yesterday, with RC1, it was better.

Code:
v:\> time /s time-b.nist.gov
TCC: Timeout. "time-b.nist.gov"

v:\> time /s time-b.nist.gov
TCC: Timeout. "time-b.nist.gov"

v:\> time /s time-b.nist.gov
TCC: Timeout. "time-b.nist.gov"
I have no difficulty contacting the server as my TIMESYNC plugin shows:

Code:
v:\> for /L %i in (1,1,10) (timesync time-b.nist.gov /n | grep off)
Estimated local time offset: 0.014 seconds
Estimated local time offset: 0.014 seconds
Estimated local time offset: 0.015 seconds
Estimated local time offset: 0.018 seconds
Estimated local time offset: 0.017 seconds
Estimated local time offset: 0.019 seconds
Estimated local time offset: 0.016 seconds
Estimated local time offset: 0.018 seconds
Estimated local time offset: 0.017 seconds
Estimated local time offset: 0.015 seconds
In addition, its timeout is a whole minute (!) and there's no way to interrupt it. A timeout of anything more than a second or two is inappropriate for NNTP.

Here are a couple more tries ... with TIME /S, then with TIMESYNC

Code:
v:\> for /L %i in (1,1,10) (time /s time-b.nist.gov)
TCC: Timeout. "time-b.nist.gov"
TCC: Timeout. "time-b.nist.gov"
System time updated to : Fri  Oct 23, 2009  17:21:08
TCC: Timeout. "time-b.nist.gov"
TCC: Timeout. "time-b.nist.gov"
TCC: Timeout. "time-b.nist.gov"
TCC: Timeout. "time-b.nist.gov"
TCC: Timeout. "time-b.nist.gov"
TCC: Timeout. "time-b.nist.gov"
TCC: Timeout. "time-b.nist.gov"

v:\> for /L %i in (1,1,10) (timesync time-b.nist.gov /n | grep off)
Estimated local time offset: 0.004 seconds
Estimated local time offset: 0.0000 seconds
Estimated local time offset: -0.001 seconds
Estimated local time offset: 0.002 seconds
Estimated local time offset: 0.001 seconds
Estimated local time offset: -0.000 seconds
Estimated local time offset: -0.004 seconds
Estimated local time offset: 0.004 seconds
Estimated local time offset: 0.004 seconds
Estimated local time offset: 0.001 seconds
 
Also, when no server is specified on the command line and the command times out, the error message just says

Code:
TCC: Timeout. ""

...with an empty pair of double quotes. Would it be possible to include the name of the default time server in the error message?
 
On Fri, 23 Oct 2009 19:32:53 -0500, rconn <> wrote:

|---Quote---
|> TIME /S doesn't seem to work very well. Yesterday, with RC1, it was
|> better.
|---End Quote---
|Nothing has changed in the TIME /S code in several years.

Perhaps it has worked poorly for years (and I was lucky yesterday).
--
- Vince
 
On Fri, 23 Oct 2009 21:25:29 -0500, rconn <> wrote:

|---Quote---
|> |---Quote---
|> |> TIME /S doesn't seem to work very well. Yesterday, with RC1, it was
|> |> better.
|> |---End Quote---
|> |Nothing has changed in the TIME /S code in several years.
|>
|> Perhaps it has worked poorly for years (and I was lucky yesterday).
|---End Quote---
|Have you changed your Windows version recently?

No. I have the original XPSP3 install from whan this computer was new, 12/2008.

In a few tries, it seems v10's TIME /S doesn't work any better.
--
- Vince
 
> |---Quote---
> |> |---Quote---
> |> |> TIME /S doesn't seem to work very well. Yesterday, with RC1, it
> was
> |> |> better.
> |> |---End Quote---
> |> |Nothing has changed in the TIME /S code in several years.
> |>
> |> Perhaps it has worked poorly for years (and I was lucky yesterday).
> |---End Quote---
> |Have you changed your Windows version recently?
>
> No. I have the original XPSP3 install from whan this computer was new,
> 12/2008.
>
> In a few tries, it seems v10's TIME /S doesn't work any better.

The default time server has apparently belly up sometime in the last few
days.
 
On Fri, 23 Oct 2009 22:52:30 -0500, rconn <> wrote:

|The default time server has apparently belly up sometime in the last few
|days.

I wsn't using the default server. I used one to which I can connect with ease
(10 times in 2.5 sec.).

v:\> time /s time-b.nist.gov
TCC: Timeout. "time-b.nist.gov"

v:\> for /L %i in (1,1,10) (timesync time-b.nist.gov /n | grep off)
Estimated local time offset: 0.003 seconds
Estimated local time offset: -0.001 seconds
Estimated local time offset: 0.002 seconds
Estimated local time offset: 0.003 seconds
Estimated local time offset: 0.003 seconds
Estimated local time offset: 0.001 seconds
Estimated local time offset: -0.000 seconds
Estimated local time offset: 0.003 seconds
Estimated local time offset: 0.003 seconds
Estimated local time offset: 0.003 seconds

v:\> time /s time-b.nist.gov
TCC: Timeout. "time-b.nist.gov"
--
- Vince
 
The default time server has apparently belly up sometime in the last few
days.

It's not quite as simple as that.

If you go into Windows Date & Time properties and put in the TC default server - clock.psu.edu - the time updates OK, though
TIME /S clock.psu.edu
doesn't work. So the server *isn't* belly-up, though for some reason it doesn't seem to work with TC any more.

Incidentally I've also tried the NTP Pool servers e.g.
pool.ntp.org
uk.pool.ntp.org
0.uk.pool.ntp.org
and none of these seem to work with TIME /S, though they all work OK in Windows Date & Time. Similar issue with these, perhaps?

[XP Pro SP3, TC 8.02 (104)]
 
It's not quite as simple as that.

If you go into Windows Date & Time properties and put in the TC default server - clock.psu.edu - the time updates OK, though
TIME /S clock.psu.edu
doesn't work. So the server *isn't* belly-up, though for some reason it doesn't seem to work with TC any more.

Incidentally I've also tried the NTP Pool servers e.g.
pool.ntp.org
uk.pool.ntp.org
0.uk.pool.ntp.org
and none of these seem to work with TIME /S, though they all work OK in Windows Date & Time. Similar issue with these, perhaps?

[XP Pro SP3, TC 8.02 (104)]

Right, same here also with hu.pool.ntp.org and ca.pool.ntp.org. And also they all work fine with Vince's timesync command. As another way of doing this (though perhaps this is just the command line variant of using the Windows GUI) the following also works for various NTP servers:
Code:
net time /setsntp:pool.ntp.org
w32tm /resync
 
Right, same here also with hu.pool.ntp.org and ca.pool.ntp.org. And also they all work fine with Vince's timesync command. As another way of doing this (though perhaps this is just the command line variant of using the Windows GUI) the following also works for various NTP servers:
Code:
net time /setsntp:pool.ntp.org
w32tm /resync

To follow up on my earlier post, the curious thing, though, is that whilst I can't get TIME /S to work at all on some timeservers, it still seems to be working more-or-less flawlessly on others e.g. NIST e.g.
nist1-ny.ustiming.org
and on a few UK timeservers that I've tried e.g.
ntp.demon.co.uk

I did wonder whether it might be a DNS thing, but TIME /S also times out on 128.118.25.3 (clock.psu.edu), whereas Windows Time & Date works just fine with both the URL and with the raw IP address.

One further bit of information: TIME /S clock.psu.edu was working OK as recently as last Sunday 18 Oct 2009, at 00:28:34 GMT. (Fortuitously I happen to have a log from then.)
 
On Sat, 24 Oct 2009 09:07:07 -0500, modio <> wrote:

|I did wonder whether it might be a DNS thing, but TIME /S also times out on 128.118.25.3 (clock.psu.edu), whereas Windows Time & Date works just fine with both the URL and with the raw IP address.
|
|One further bit of information: TIME /S clock.psu.edu was working OK as recently as last Sunday 18 Oct 2009, at 00:28:34 GMT. (Fortuitously I happen to have a log from then.)

TIME /S uses "time" (37/UDP) which is pretty ols fashioned. TIMESYNC uses NTP
(123/UDP). I found this:

"Starting on 14 April 2007 the server time.nist.gov will no longer respond to
requests for time in the TIME format (as defined in RFC-868). These requests are
generated by a number of different programs including DATE, RDATE, and other
programs that connect to the time server using tcp or udp port 37. All of the
other NIST servers (except for time-nw.nist.gov) will continue to respond to
requests to either tcp or udp port 37 for time in the format specified in
RFC-868."

"However, this format has poor error-handling capabilities in general, and many
of the client programs that use this format are poorly written and may not
handle network errors properly. Therefore users are strongly encouraged to
switch to the Network Time Protocol (NTP), which is more robust and provides
greater accuracy. We eventually intend to phase out support for the TIME format
on all servers."

It would seem that for nist and psu the priority of "time" is quite low.
--
- Vince
 
Back
Top