From: livibetter on
I forgot to mention I redirect stderr to /dev/null, because curl
returns error code 56 to me with this message "curl: (56) Failure when
receiving data from the peer"


On Jun 4, 11:20 am, livibetter <livibet...(a)gmail.com> wrote:
> This?
>
> hwclock --utc --set --date="$(datestr="$(curlhttp://208.66.175.36:13/
> 2>/dev/null | cut -d \  -f 2-3)" ; echo ${datestr//-//})"
>
> Only hwclock, curl, cut, and Bash.
>
> PS. I didn't know I can set the time via hwclock, learned from Paul's
> post, but still didn't try to see if it does work.
>
> On Jun 4, 8:57 am, Ross <ros...(a)gmail.com> wrote:
>
>
>
> > No - it's not really a python specific need, it's just what I'm using
> > just now, and can't think of where else to ask. It's also my fav test-
> > bed, as it's so easy.
>
> > Your curl example is using grep and date which I don't have available.
> > I have no fancy libraries, just core parsing capability.
>
> > I found that NIST has some capability on various servers.
>
> > RFC 868 and 867.  I can get this
>
> > > curlhttp://208.66.175.36:13/
>
> > 55351 10-06-04 00:24:46 50 0 0   8.3 UTC(NIST) *
>
> > But I'd have a lot of parsing to pull it together.
>
> > Apparently RFC868 provides a 32bit unformated binary response, but I
> > can't make much out of it. I think my TCP client library is expecting
> > chars and is screwed by bit-boundary expectations.
> > The number is supposed to be seconds since 1900, which is just as good
> > as seconds since 1970.
>
> > Still hunting. Tho' maybe getting a bit off topic for a python msg
> > board :)
>
> > On Jun 3, 8:36 pm, livibetter <livibet...(a)gmail.com> wrote:
>
> > > I don't know what tools do you have on embedded system, but I really
> > > don't think this has to be using Python.
>
> > > Here is what I would do on a normal desktop using your unique way to
> > > set up time:
>
> > >   date -s "$(curl -s -Ihttp://example.com|grep Date | cut -d \  -f
> > > 2-)"

From: Ross on
On Jun 3, 11:20 pm, livibetter <livibet...(a)gmail.com> wrote:
> This?
>
> hwclock --utc --set --date="$(datestr="$(curlhttp://208.66.175.36:13/
> 2>/dev/null | cut -d \  -f 2-3)" ; echo ${datestr//-//})"
>
> Only hwclock, curl, cut, and Bash.
>
> PS. I didn't know I can set the time via hwclock, learned from Paul's
> post, but still didn't try to see if it does work.
>
>

Thanks for the info. Yes, I like the port 13 stuff from NIST et al
which is RFC 867 formatted, but on the hdwe the parsing is more
work.

Found a bit of port 37 RFC 868 stuff that sounds interesting. I am
able to get a long int from it now I think (e.g. 64.236.96.53:37 in
Virginia), though it seems to be a bit mangled, and doesn't work out
to the number I'd expect for a 1900 epoch. Still, I think it's usable,
and is just a single number.

I hear NIST is gradually getting away from RFC868 stuff tho' which is
too bad. Some of us don't need pS accuracy. +/- 5min is fine.

Thx for the input!