We have moved at community.getvera.com

Author Topic: lua os.date  (Read 6201 times)

Offline utz

  • Sr. Member
  • ****
  • Posts: 274
  • Karma: +0/-0
lua os.date
« on: June 25, 2011, 08:03:29 pm »
I have some problems with os.date (but maybe I just do not understand it correctly)

why does the program

Code: [Select]
#!/usr/bin/lua
print (" " ..  os.date("%H:%M:%S", 1308934197))
print (" " ..  os.date("%H:%M:%S", 1308934198))
print (" " ..  os.date("%H:%M:%S", 1308934199))

output

Code: [Select]
17:49:04
17:49:04
17:49:04

and not

Code: [Select]
17:49:04
17:49:05
17:49:06

I thought that counting up one represents one second?

Offline futzle

  • Beta Testers
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: lua os.date
« Reply #1 on: June 25, 2011, 08:15:28 pm »
I bet this is the single-precision-float UI4 bug.  If I run on a Lua interpreter on a real computer, I get the expected result:

Code: [Select]
% lua -e 'print (" " ..  os.date("%H:%M:%S", 1308934197))
print (" " ..  os.date("%H:%M:%S", 1308934198))
print (" " ..  os.date("%H:%M:%S", 1308934199))'
 02:49:57
 02:49:58
 02:49:59

What's happening is that the numbers you are entering are being converted to single-precision floats, which only have about six decimal digits of precision.  At six digits of precision, all of those numbers are the same.

I'm not aware of a workaround.  Lua has a habit of converting integers to floating-point numbers willy-nilly, and there's no way to turn them back into integers.

We've raised a bug with Micasaverde to update the version of OpenWrt that Vera uses to a later version that uses double-precision floating-point numbers in its Lua engine.

Offline utz

  • Sr. Member
  • ****
  • Posts: 274
  • Karma: +0/-0
Re: lua os.date
« Reply #2 on: June 26, 2011, 03:22:05 am »
@futzle
Thanks for confirming this. I thought I have gone mad.

I know vera is not a realtime system but it should be able to track events in the order of a second (or a few seconds). I hope there will be an update some point that will fix it (from my point of view, getting timing right on a system processing events is more important than new UI features)




Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Re: lua os.date
« Reply #3 on: June 26, 2011, 03:59:21 am »
From http://bugs.micasaverde.com/view.php?id=1451:

micasaverde:
Quote
This is subjective, and it's an issue with OpenWRT backfire, not really in our code. The next time we upgrade the base image this should be resolved. But, upgrading the base image is a very time consuming process that always results in hundreds of crashed units that get returned under RMA because of users cycling power or something while the base image is writing. So we don't upgrade the base operating system often.

AFAIK, there never was an upgrade of the base operating system for Vera V2.

Judge for yourself ...


Offline utz

  • Sr. Member
  • ****
  • Posts: 274
  • Karma: +0/-0
Re: lua os.date
« Reply #4 on: June 26, 2011, 01:59:09 pm »
I can see that an upgrade may cause some support problems and that they want to avoid upgrading for everyone. However, is there a manual way of upgrading OpenWRT (is it a standard installation or is it a very customized thing I will spend hours compiling/installing/configuring)? In my opinion this is a quite major problem that needs fixing (if it should not be fixed for everyone, maybe I can just fix it on my system)

Offline futzle

  • Beta Testers
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: lua os.date
« Reply #5 on: June 26, 2011, 05:27:30 pm »
is there a manual way of upgrading OpenWRT

There should be.  OpenWrt is GPL, so MCV is supposed to provide us with a copy of the source, so that we can compile it ourselves, for situations exactly like this.

I've subtly suggested to MCV on several occasions that they are currently in violation of the GPL for not making their modified OpenWrt available.  There's never been any response.