Os.date() problem? [SOLVED]

Help and Feedback Scripting Support
#14 
while wait() do
if date[“month”] == 11 and date[“day”] == 29 and date[“hour”] == 19 and date[“min”] >= 49 then
print(“Event”)
else
print(“Noevent”)
end
end
#15

You have to update the date in every iteration, otherwise this makes no sense.

while wait(1) do
    local date = os.date("*t", os.time())
    if date["month"] == 11 and date["day"] == 29 and date["hour"] == 19 and date["min"] >= 49 then
        print("Event")
    else
        print("Noevent")
    end
end
1 Like
#17

i did and now it prints:

bad argument #1 to ‘date’ (string expected, got no value)

#18

Did you copy the exact code that I posted?
Try this:

while wait(1) do
    local date = os.date("*t")
    if date["month"] == 11 and date["day"] == 29 and date["hour"] == 19 and date["min"] >= 49 then
        print("Event")
    else
        print("Noevent")
    end
end
#19

It worked! And my last question: In studio the time used for os.date() is from your computer, and when it is playing on roblox servers will use UTC time? (Costa rica time + 6 Hours)

#20

image
image1051×109 14.6 KB

Source: os

I’m not sure how it will work in a server script so I advise you to check it.

1 Like
#21

@Conejin_Alt

local date = os.date("*t")

Will give the local time. This is based on where the server exists, so it can vary significantly.

local date = os.date("!*t")

Will ALWAYS give UTC time. This is very useful for events, as it will be synced across all servers (with maybe slight delays, nothing more than a second).

CC
@Kacper
While wait() do loops are generally a bad practice.
For more information, see this article:

Ported over the the developer forum by @colbert2677 made by @cntkillme.

#22

No, only while wait() do loops are a bad practice. While wait(interval) do loops with a reasonable interval are okay. And all of that depends on what you want to achieve.

#23

i just got the code, and i noticed that if i use while true do() can cause the event repeats infinitely, so i just added another script that handles the event and in the script of the time, it will enable the handler of the script.

script.Parent.Disabled = false
instead of print()

and the parent is another script (handler:

game.Workspace["Final Boss"]:Play()

that right now im at the song part.

#24

They are both bad practices. Please read the article I attached before you respond to my post. wait() is bad on itself. Using the returned value from wait in a while loop is the bad practice I am referring to.

Please read this before responding:

1 Like
#25

Another solution would be to have a boolean variable which you toggle. This could also be a BoolValue which is read from other scripts. The choice is yours.

#26

why not use “repeat until” code?

#27

That would also be fine; Its just generally while loops are more common.

while true do
    --Runs every second
    wait(1)
end

repeat
   --Runs every second
   wait(1)
until false

Generally, I prefer a while loop, but it’s your choice.

For this scenario, you could also use .Stepped or .Heartbeat.

#28

I have already read it few times. Everyone who reads this without any understanding and experience will say that while wait(interval) do loops are bad practices. But the truth is that the only reason you shouldn’t use the while wait(interval) do loop is when in every iteration you do something that could be done every time a certain event is fired. We will not connect this date update to heartbeat or renderstepped as this makes no sense to refresh it that often.

#29

While loop vs .Heartbeat

It doesn’t fall into a which is better category, it falls into how accurate he wants the event to be. If he wants it to be slightly in accurate, the while true do wait(1) end loop would be better. If he wants it to be accurately synced across all servers, the .Heartbeat would be better.

While wait do idiom

As for the while wait do idom, you clearly did not read it thoroughly. Read the following quote:

The while wait do idiom applies to ANY value of n, not just nil.

It’s not about n, but about using the truthy value returned from the wait function.

#30

And what is in your understanding the reason to never use the while wait(n) loop?

#31
  • You shouldn’t use something because everyone else uses it
  • Its quick and easy is not a excuse for using it
  • Its mainly bad practice, as you rely on the value return from wait (actual time waited) to be a truthy value.
  • You don’t have to rely on the truthy value, it’s not the only way to get the same result

As for more replies, please take this into DMs. I don’t want to clutter this topic any more than it has been.

#32

Both types of while wait loops are bad code and abuse of the while condition: the only change is that you’re specifying different timeouts for each case. Wait without n, alone, is an isolated case for which a resource also exists for.

If you want to add an intermission between iterations, do it in the iteration itself. There is no “truth” other than it is bad practice to rely on the fact that wait returns a truthy value to yield each iteration and at the beginning no less, stripping you of yield control per iteration.

The condition of a while loop is intended to determine when the loop should terminate. It becomes abusive when you start putting break statements inside iterations because you couldn’t be bothered to use the condition properly.

#33

Then what we should use? instead of while true loops

#34

You should use while true loops in the case of needing a non-terminating while loop, never said you shouldn’t. The point of concern is against while wait, which improperly uses the while condition.

It’s best to read the post that was left behind by Timothy as it includes the thread on while wait loops and why they should be avoided.

1 Like