Plain simple unix timestamp with an HTTP GET

Discussion in 'Python' started by Ross, Jun 4, 2010.

  1. Ross

    Ross Guest

    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, Jun 4, 2010
    1. Advertisements

  2. Ross

    livibetter Guest

    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 | grep Date | cut -d \ -f
    livibetter, Jun 4, 2010
    1. Advertisements

  3. Ross

    Ross Guest

    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
    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 :)
    Ross, Jun 4, 2010
  4. Ross

    Paul Rubin Guest

    I haven't used this in a while and can't promise it still works:
    Paul Rubin, Jun 4, 2010
  5. Ross

    livibetter Guest


    hwclock --utc --set --date="$(datestr="$(curl
    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, Jun 4, 2010
  6. Ross

    livibetter Guest

    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"
    livibetter, Jun 4, 2010
  7. Ross

    Ross Guest

    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

    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. 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!
    Ross, Jun 4, 2010
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.