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...@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...@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...@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-)" -- http://mail.python.org/mailman/listinfo/python-list
