3

os.time() in Luaj returns time in milliseconds, but according to lua documentation, it should return time in seconds.

  1. Is this a bug in Luaj?
  2. And Can you suggest a workaround that will work with Luaj(for java) and real Lua(c/c++)? because i have to use the same lua source for both applications.(cant simply divide it with 1000, as they both have return different time scale)

example in my lua file: 

local start = os.time()
while(true) do
    print(os.time() - start)
end

in c++ , i received output: 

1
1
1
...(1 seconds passed)
2
2
2

in java (using Luaj), i got: 

1
...(terminate in eclipse as fast as my finger can)
659
659
659
659

fyi, i try this on windows

Cœur
  • 37,241
  • 25
  • 195
  • 267
bysreg
  • 793
  • 1
  • 9
  • 30
  • os.time() returns the time in seconds. You are probably confusing *units* with *precision*. `12.423` is a time in seconds, with millisecond precision. – David Schwartz Apr 24 '13 at 01:26
  • os.time() **should** returns time in seconds. but in **Luaj**, it instead returns in miliseconds(i think, at least when i change it to 1000, it feels like a second) – bysreg Apr 24 '13 at 01:29
  • 1
    Can you give us an example? I think it's returning the time in seconds but with millisecond precision and you are seeing the precision and confusing it with the units. – David Schwartz Apr 24 '13 at 01:37
  • @DavidSchwartz i have added code example in my question above – bysreg Apr 24 '13 at 04:02

4 Answers4

10

Yes there's a bug in luaj.

The implementation just returns System.currentTimeMillis() when you call os.time(). It should really return something like (long)(System.currentTimeMillis()/1000.)

It's also worth pointing out that the os.date and os.time handling in luaj is almost completely missing. I would recommend that you assume that they've not been implemented yet.

Alex
  • 1,017
  • 5
  • 11
  • after searching thru the code to check on your statement, i confirmed that luaj implementation use System.currentTimeMillis() for the implementation of os.time() (you can see it in OsLib.java line 308) – bysreg Apr 24 '13 at 16:38
2

Lua manual about os.time():

The returned value is a number, whose meaning depends on your system. In POSIX, Windows, and some other systems, this number counts the number of seconds since some given start time (the "epoch"). In other systems, the meaning is not specified, and the number returned by time can be used only as an argument to os.date and os.difftime.

So, any Lua implementation could freely change the meaning of os.time() value.

Egor Skriptunoff
  • 23,359
  • 2
  • 34
  • 64
  • " ... In POSIX, **Windows**, and some other systems, ... counts the number of **seconds**", sorry i should have mentioned what my system is. I use windows. so it should return number of seconds right? – bysreg Apr 24 '13 at 05:44
  • 1
    @bysreg - The words about POSIX, Windows are about vanilla Lua only. Luaj doesn't work on Windows, it works on Java. ;-) – Egor Skriptunoff Apr 24 '13 at 05:52
  • it seems there are no better way than to use os.clock(), so i'm choosing this as the answer – bysreg Apr 24 '13 at 17:17
2

It appears like you've already confirmed that it's a bug in LuaJ; as for the workaround you can replace os.time() with your own version:

if (runningunderluaj) then
  local ostime = os.time
  os.time = function(...) return ostime(...)/1000 end
end

where runningunderluaj can check for some global variable that is only set under luaj. If that's not available, you can probably come up with your own check by comparing the results from calls to os.clock and os.time that measure time difference:

local s = os.clock()
local t = os.time()
while true do
  if os.clock()-s > 0.1 then break end
end
-- (at least) 100ms has passed
local runningunderluaj = os.time() - t > 1

Note: It's possible that os.clock() is "broken" as well. I don't have access to luaj to test this...

Paul Kulchenko
  • 25,884
  • 3
  • 38
  • 56
1

In luaj-3.0-beta2, this has been fixed to return time in seconds.

This was a bug in all versions of luaj up to and including luaj-3.0-beta1.

Jim Roseborough
  • 201
  • 1
  • 4