Luau Recap: June 2020

These are all great changes; I’ve been using elapsedTime() as of late because it doesn’t do the same weird time zone shifts that tick() does. os.clock() is definitely going to make my life so much easier!

I’m still anxiously waiting for the type checker to be released in full so that I can use it in production, but I also appreciate a well-done language over a rushed one.

Particularly hoping to see more with function generics, importing module types statically without requiring that module at runtime, and having classes as first-class citizens. I can’t wait to start an upcoming project in a typed luau codebase, but the type system seems to lack a few more features for me to use it the way I want to use it. I’m hoping syntax can be added in the future if not added at release at the very least.

Well, we can’t really rename things :slight_smile: can introduce new names and deprecate old names. In general I’m not sure this deserves a global, so at that point I’d probably bias to some set of RunService properties with descriptive names…

We’re thinking about this but nothing on the immediate roadmap. (edit oh I should mention that we’re considering structs with named fields of course :smiley: see records from


Secretly more excited for this than any other update.

That being said, since you’re basically overhauling the language… can I get a continue? :pleading_face:

1 Like

After giving it some more thought, I am coming before you to humbly ask for an update on function generics. Namely: are they still on the roadmap for typed Luau?

Also, as Luau is formally declared a superset, can we have .luau as a valid file type in Studio for saving scripts to a file and importing them from files? It makes sense to distinguish between Lua and Luau at this point.





I completely converted my game from tick() to os.clock() with no problems. I almost always calculated time deltas using tick() to keep timing accurate even if something throttles or skips a frame, and it’s a relief to have a precise method like os.clock() that won’t lose floating point precision as we get further from the unix epoch.


Yeah syntax for generic functions is on the roadmap but after we get types out of beta


Is this beta feature enabled for publish places as of yet? :crossed_fingers: :crossed_fingers:

I don’t think os.time() is working properly when passing a table date input into it.


print(os.time{year=1970, month=1, day=1, hour=0})

With timezone set to London I get:

With timezone set to UTC-8 I get:

Even with the example on the wiki:



I think this has broken a scheduling feature on my game. I was using r ="*t", timestamp) and os.time({r.year, r.month, ...}) to get the UTC timestamp of the local adjusted time of another UTC timestamp.

(This is in studio on Windows 10)

1 Like

That seems to be expected behavior. 28,800 seconds is exactly 8 hours and os.time returns the local time.

1 Like

Thank you, misreading things as always sorry!

Will there be potential switch statements in the fold later down the line? I’m curious how that may turn out to be honest.

What is this SECRET TOOL that is mentioned?


Ok, Nice, i will go check it out

DarkTheme Lovers, me included:
(Support DarkTheme, pls)

But finaly a website for Luau! Wait, Luau is a new language or it still is Lua? If this is a new language, then why create a new language from another language istead of update the version of Lua?


Example: Syntax - Luau
Is it possible to remove the .html? Idk, it would be nice. But this is a really, really big and good update, thanks Roblox!

To be precise, Luau is a superset of Lua 5.1.

This is explained in the GitHub Pages of Luau.

Yes, just remove it yourself?

1 Like

Ok, thanks, i am alway learning new stuff here.

My bad, sorry!

I know how websites and html are working, what i am trying to say is, is it possible to redirect directly without the « .html »? But its a small feature that could be ignored…

Thank you for taking the time to help me and explain everything! (Now I just hope that a DarkTheme version will be released, at least this one…)

Thanks for letting us know! This is actually an accidental mishap, which is a consequence of us upgrading our os. implementation to follow Lua 5.x. We discussed this internally and decided that we should go back to UTC.

Specifically, in Roblox:

  • Up until end of 2017, os.time() with a table argument assumed the specified date was in local time
  • Since 2018 and up until last month, os.time() with a table argument assumed the date was in UTC
  • Last month we changed it to assume local time zone (accidentally); this is also what Lua 5.x does.

We discussed this and feel like this should be changed back to UTC - both on the grounds of it being a regression and inadvertently breaking code, but also on the grounds of UTC making more sense, since os.time() with no arguments also works in UTC.

So this will be fixed in about two weeks.


Why is tick() getting deprecated? What would we use instead as a stopwatch with milliseconds?

time() and os.clock(). They are better as they aren’t affected by float imprecision as tick is.

time() shows seconds since the game started, while os.clock() shows seconds since Lua started. This means that in Studio time() always returns 0 until you start the game, while os.clock() shows seconds since you opened the program. They don’t have much of a difference in-game though.

Your not getting my point. os.clock() doesn’t have miliseconds. and tick does.