Plain simple unix timestamp with an HTTP GET

[Ross]

I'd like to just quickly and with a minimum of parsing (ie no screen-
scraping) get a unix epoch timestamp (or another format if necessary).

I thought with a quick second search on Google I'd find a URL where I
could do a simple urllib2 based HTTP GET and have a timestamp
returned to me. I don't want to use NTP.
I need this because I want to run it on an embedded system where I
don't have a local timesource, but do have a network service. I'm very
low on memory tho.

I can set up my own service on django I suppose, and just render back
the timestamp from datetime.time() but SURELY someone else is already
doing that?

My googling has fallen flat. Any suggestions.

Thanks in advance!

-Ross.

 

[livibetter]

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 -I http://example.com | grep Date | cut -d \ -f
2-)"

 

[Ross]

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

curl http://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

 

[Paul Rubin]

I'd like to just quickly and with a minimum of parsing (ie no screen-
scraping) get a unix epoch timestamp (or another format if necessary).

I haven't used this in a while and can't promise it still works:

http://www.nightsong.com/phr/python/setclock.py

 

[livibetter]

This?

hwclock --utc --set --date="$(datestr="$(curl http://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.

 

[livibetter]

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"

 

[Ross]

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!