Odd Time.time results

From following script:

public void Awake()
        {
            var i = 0;
            while (i < 1000000)
            {
                Debug.Log($"CurrTime: {Time.time:0.000000000000000000000000}. DeltaTime: {Time.deltaTime}");
                i++;
            }
        }

All of which returned:

CurrTime: 0.000000000000000000000000. DeltaTime: 0.02
UnityEngine.Debug:Log(Object)

Even without formatting, it just returns “0”.
I could buy into explanation that deltaTime is based on framerate whilst Time is based on real time, but it permanently stuck at 0, even with this insane precision. I expected at least a nanosecond, or anything but 0. What happens?

I tried a delayed coroutine and it works:

        public IEnumerator Yep()
        {
            var i = 0;
            while (i < 10000)
            {
                Debug.Log($"{i} CurrTime: {Time.time:0.000000000000000000000000}. DeltaTime: {Time.deltaTime}");
                yield return null;
                i++;
            }
        }

My method needs Time.time to work and it cannot be invoked by Coroutine.
So, what gives?

Many time values will be consistent throughout an entire frame,i.e. no matter how often you call it within a single frame, it’ll be the same value. This applies to Time.time as well, and that’s pretty useful in many cases.

However, occasionally you need the actual “real time” that has passed since the application was started, and that’s what Time.realtimeSinceStartup exists for.

1 Like

If you go compute-bound in a non-coroutine while(true) loop, expect to burn down your mobile device battery at approximately 5x to 25x the normal rate, depending on device. This is a great way to get people to uninstall your game because it flattens their battery and makes their phone too hot to hold.

If you’re doing it on the PC that is slightly more acceptable, but generally with Unity you want to avoid infinite loops and anything that requires sub-frame timing precision. You’re just going to always struggle if you insist on these things. If you truly insist, it might be best to just write your own basic Windows/Mac/iOS app that takes these unusual design requirements into account and accommodates them in a non-compute-heavy way.

Here is some Unity timing diagram help: