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.
     
    Ross, Jun 4, 2010
    #1
    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 http://example.com | grep Date | cut -d \ -f
    2-)"
     
    livibetter, Jun 4, 2010
    #2
    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
    #3
  4. Ross

    Paul Rubin Guest

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

    http://www.nightsong.com/phr/python/setclock.py
     
    Paul Rubin, Jun 4, 2010
    #4
  5. Ross

    livibetter Guest

    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, Jun 4, 2010
    #5
  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
    #6
  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
    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!
     
    Ross, Jun 4, 2010
    #7
    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.