Small inconsistency in date()

I noticed a couple of bizarre readings in my logs and have dug up an observation about date().

I need to execute a few checks every minute, on the minute. I was posting the time every time I did this and noticed it would sometimes say that the time was sometimes hour:(min-1):59 rather than hour:min:0

checking through the code I saw I was calling date() twice, the first time with no argument and the 2nd with the argument time(). I would have expected them to return the same values,or at the very least for the 2nd call to return a time that occurs AFTER the 1st. However, intermittently it returns a time BEFORE the first call.

This is some simple AGENT test code to demonstrate:
function timer_test(){ imp.wakeup(1,timer_test); local t1=date(); local t2=date(time()); if (t2.sec!=t1.sec) server.log("ERROR: t1="+http.jsonencode(t1)+" t2="+http.jsonencode(t2)); } timer_test();

I only had to wait about 2 hours for a bundle of messages in the device log to turn up.

One might expect t2.time to be occasionally larger than t1.time, but not the other way round.

I haven’t tried it in the device yet.

Also interesting to note the undocumented date().usec field. Is this usable?

Wow, that’s on the agent? On the agent date() ends up in Posix gettimeofday(), and time() ends up in ISO C time(). I didn’t realise they ran on different timebases.

The usec field is usable. On the agent it’s derived from NTP and is probably accurate to about 1ms. On the device it’s currently always zero, though imp003 (only) can actually do better than that (1/256ths of seconds), which we intend to expose in a future release.

Peter

It turns out that this is probably http://stackoverflow.com/questions/22917318.

Peter

Yes, I’m still using both date() (for time when I want detail) and time() (for time when I want speed and brevity) in my code, but I avoid any comparisons between them.