Making a clock that shows the player’s real life time is actually quite easy!
First create your GUI
Example:
then when you have that done, create a local script inside your text and put in this code
local RS = game["Run Service"] --Gets Run Service
while RS.Heartbeat:Wait() do --Loops
local dt = DateTime.now() --Gets the time
script.Parent.Text = dt:FormatLocalTime("LT", "en-us") --Sets the time
end
you can change the “LT” to be anything if you want a different format. Link to DevHub article (it’s at the Composite Tokens area)
Looks quite nice! A bit of advice though, I wouldn’t recommend using wait(0.1) for a loop that’s going to be run many times. My suggestion would be to change this to a RunService loop.
Either:
while RunService.Heartbeat:Wait() do
local CurrentTime = DateTime.now()
script.Parent.Text = CurrentTime:FormatLocalTime("LT", "en-us")
end
or
RunService.Heartbeat:Connect(function()
local CurrentTime = DateTime.now()
script.Parent.Text = CurrentTime:FormatLocalTime("LT", "en-us")
end)
Looks great! (I like how you recorded this at midnight haha.) For one, with the while loop, if you want to keep the wait and reduce lines, then do this instead:
while wait(0.1) do script.Parent.Text = DateTime.now():FormatLocalTime("LT", "en-us") end
It does the same thing and only takes up one line of code.
I don’t think something like this would warrant for a whole RunService event. A regular wait() is already fast for something like this. wait() can be slightly inaccurate sometimes and that is why it is replaced with a RunService event, however, this isn’t something that should account for accuracy and be updated faster than a regular wait() loop.
the second piece of code isn’t a loop
and they both function in different ways
the while loop will run all the code and then wait a frame and then run again and so on
the RunService function will run every single frame(a certain part of the frame) and it won’t wait for the code to finish to run again, a debounce can make it act like a loop tho
you probably already know that or maybe you don’t, I just wanted to say that
wait() can be bad. (depends on how much yields you use in your scripts.)
The reply was to explain why a RunService event is not needed. In most cases, people replace wait() with different RunService events such as: Heartbeat, RenderStepped, or Stepped because they are accounting for accuracy. Using these events won’t guarantee a perfect solution, because RunService events can sometimes still be inaccurate.
Using a RunService event here is unneeded and can take more memory than necessary. There are much more superior and greater uses of RunService events you can put in your code. Integrating a RunService event that makes almost no difference to that of a wait() can be detrimental to future uses because you may run into more delay or lag depending on how much more you use it.
TL;DR: Only use RunService events when it is necessary, such as: accounting for better accuracy or wanting something to run faster than a wait(). A timer like this is fine with a regular wait() (maybe even a longer wait() time since the timer only updates every one minute.)
I dont think it should be set because it worked for me without any parameters. If I’m wrong, you can get the locale with LocalizationService.SystemLocaleId property.
So it worked or not? I just tested this in Studio and it didn’t work without second parameter. When I said that it doesn’t require parameters I was talking about function DateTime.new():ToLocalTime() and then I realized that @OP uses a different function.
, but I do know the differences between both.