Possibly a bug in os.time()

[Alex-1248]

Mc 1.7.10
OpenComputers-MC1.7.10-1.8.1+c71c147-universal

I ran the file with the following content:

print(os.time()/(60*60*24))
print(os.date())

The first line returns the number of days elapsed since the start of the game. For some reason it returns a number close to x.0 when the in-game time is 01:00 and returns a number close to x.5 when the in-game time is 13:00. Judging by the position of the sun and moon, os.date() shows the correct time. Looks like os.time() counts down from 01:00 instead of 00:00. Is this intentional behavior?

[asiekierka]

Apparently so:

        // Game time is in ticks, so that each day has 24000 ticks, meaning
        // one hour is game time divided by one thousand. Also, Minecraft
        // starts days at 6 o'clock, versus the 1 o'clock of timestamps so we
        // add those five hours. Thus:
        // timestamp = (time + 5000) * 60[kh] * 60[km] / 1000[s]
        LuaValue.valueOf((machine.worldTime + 5000) * 60 * 60 / 1000)

@fnuecke , got any advice?

[fnuecke]

Hrm, at the very least it appears to be inconsistent with the date method, which does a +6000 instead. In fact, that seems to have been changed a long long time ago.

How this offset by .5 comes to be (as opposed to in date) I have no idea, however, I'm afraid. Maybe GameTimeFormatter.parse isn't quite correct, so os.time is correct, but the os.date output isn't.

[asiekierka]

Okay, I understand now!

os.time() in Lua returns the system epoch (always tied to UTC), but os.date() returns the system time (tied to the local system timezone). As such, the one-hour difference is probably caused by the fact you were in GMT+1 while coding this ;-)