koobas.hobune.stream
Time.realTimeSinceStartup behaves weirdly when sending app to background or locking the screen.
From the Unity script reference: realtimeSinceStartup also keeps increasing while the player is paused (in the background).
I put the application to background and it gave the correct amount of time since the app started for smaller durations of backgrounding (less than 3 mins). But it started giving wrong values for longer durations of backgrounding (5-10 mins). Is this a bug in Unity? Has anyone else faced the same issue?
BTW, this happens across devices. Tested on Android 4.1 and iOS 7.0
I made some tests and yes in some cases the value is smaller than it should be or than it was already. It's actually a strange bug since like the docs state it's based on the system time. If the value is messed up that would mean the start-offset got messed up somehow.
Anyways, you can use a script like this one. It does the exact same thing but doesn't have this strange bug:
// C#
// TimeHelper.cs
using UnityEngine;
using System.Collections;
public class TimeHelper : MonoBehaviour
{
private static System.DateTime m_StartTime;
statis TimeHelper()
{
m_StartTime = System.DateTime.Now;
}
public static float realtimeSinceStartup
{
get
{
var timeSpan = System.DateTime.Now.Subtract(m_StartTime);
return (float)timeSpan.TotalSeconds;
}
}
}
Simply attach the script to a gameobject in your first scene. That will force the static constructor to initialize the offset variable. Keep in mind if the device needs the memory your app might get wiped out and if you "switch back" it's actually restarted. However you will notice that since the splash screen will be visible again.
To get the correct time, just replace your Time.realtimeSinceStartup with TimeHelper.realtimeSinceStartup.
Hey, thanks for the prompt reply. Unfortunately, the snippet of code that you sent won't be very helpful because the end user can change the system time and that would affect System.DateTime.Now.
To counter this issue, we were pinging the server to get the serverTime, but that happened only once during app launch and we were relying on realtimeSinceStartup. Now that that idea is kind of failing, we have decided to get the updated time from the server when the app comes back to foreground.
It you need this to prevent cheating, then yes, you should use an independent source for your time. $$anonymous$$ake sure you secure the WWW request at least with a hash / checksum ;). Url redirection and packet tempering isn't that hard on Android ;)
Time.realtimeSinceStartup wouldn't have worked anyways since, as you can read in the docs, it's also based on the system time.
Well, from the multiple tests that I have conducted, I figured out that realtimeSinceStartup is independent of device time (time returned by the system timer is not equal to the device time itself). So it can obviously be trusted to get delta time, in a case where the app remains in the foreground at all times.
To fix the background issue, you would need to ping a server and get the latest serverTime.
