Message Boards Message Boards

WolframScript: Error involving time, import from URL, and StringJoin

It's me again with strange symptoms (WL 11.0 / Windows 10 / native command line)... I have this piece of code that reads the NIST randomness beacon:

First[Cases[Import["https://beacon.nist.gov/rest/record/"<>ToString[UnixTime[]],"XML"],XMLElement["outputValue",{},{x_}]:>x,Infinity]]

The code works just fine in a notebook and returns a string with the current random number, which looks like this:

"60872A7889BE4EF63E00D84610C5098E6D4696C262C02ADA3CAD4A886E7B1FF2F95A713F6450FA6E2E816932E7E276E3E639517BEE4137D28D8449C9008BB7F5"

So far, so good. Now consider the following two scripts; the first one contains the code I actually want to run:

"beacon.wl":

#!wolframscript
Print[First[Cases[Import["https://beacon.nist.gov/rest/record/"<>ToString[UnixTime[]],"XML"],XMLElement["outputValue",{},{x_}]:>x,Infinity]]]

The second script contains separate tests of everything that happens, i.e. converting UnixTime to a string, doing a StringJoin with that and another string, and finally importing the results from the NIST website for a pre-determined time:

"test.wl":

#!wolframscript
Print[ToString[UnixTime[]]];
Print[ToString[UnixTime[]]<>"moo!"];
Print[First[Cases[Import["https://beacon.nist.gov/rest/record/1472807495","XML"],XMLElement["outputValue",{},{x_}]:>x,Infinity]]];

And here's what happens when I run both script files on the local kernel vs. on the cloud kernel: enter image description here

It seems as though the beacon script and tests all work locally, the tests also work in the cloud, but the cloud kernel doesn't like the complete code for some reason. I could probably circumvent the problem with an API call, but I'd rather understand what's going on here so that I can avoid (or at least anticipate) the issue in the future. Any ideas? The -v option wasn't helpful. An Evaluate around the StringJoin didn't change anything either.

POSTED BY: Bianca Eifert
4 Replies

Hm, yeah, it must be something like that. I suppose I could just consistently use yesterday's signal depending on the application. Thanks again for your help!

POSTED BY: Bianca Eifert

Hi Bianca, it is complicated. Maybe it is related to leap seconds, maybe to time zones. Notice that also Java has issues with this.

POSTED BY: Rolf Mertig

Hi Rolf, thanks for your reply and for taking the time to investigate the problem! Times in the past do indeed work, even times that are only a minute in the past. (I tried this using ToString[UnixTime[]-60] to keep the call to UnixTime in the mix.) That's quite fascinating.

Time zones can't be the issue because unix time is independent of time zones by definition. Also, going back in time by just a minute already works, and that's obviously much less than the time zone difference.

For times that are actually in the future such as Tomorrow I also get the "Unable to evaluate" result for a cloud script, but in a local script I get the expected 404 error from the NIST servers instead... I don't see why the cloud kernel wouldn't just pass that error on though.

This is still mysterious to me. Maybe there is an error of a few seconds in some clock on the Wolfram server that leads to a slightly-in-the-future timestamp being sent to the NIST server.

POSTED BY: Bianca Eifert

This will work: enter image description here

The important issue is that NIST does not like time stamps from the future. I.e., their future. Try

First[Cases[
  Import["https://beacon.nist.gov/rest/record/" <> 
    ToString[UnixTime[Tomorrow]], "XML"], 
  XMLElement["outputValue", {}, {x_}] :> x, -1]]

in a notebook from Germany and it will not work either. So, UnixTime[] in your original script is a time in the future as seen from the US (server) (when sent from the Wolfram cloud which is also in the US somewhere).

Therefore UnixTime[Yesterday] instead of UnixTime[] will fix your script.

Rolf

POSTED BY: Rolf Mertig
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract