Timestamp is offset in WebGL build

Unity Engine
, , ,
1

I have a problem with timestamps not being displayed correctly for me in my WebGL builds. They are perfectly fine in Windows Builds.

But in WebGL, they are offset by (currently) 1 hour. It seems to depend on my location, since a player of my WebGL game in another country wasn’t able to reproduce it - but someone in my country had the same issue.

It not only happens in the build but is also visible in the editor when the build target is set to WebGL. Which is nice because it makes testing easier … and I don’t think this is a Unity 6 specific problem.

I am using this code:
label += GetTimeString (System.DateTime.UtcNow);

Neither this, nor
System.DateTime.Now
returns the correct time for me - in the WebGL build.

While searching for a solution I read something about converting the UTC time to local time. But the solution wasn’t confirmed and was a rather large script (for my taste). I am wondering if it’s possible at all (the issue has been reported since years, if I understood correctly).

Of course I don’t want it to only work in my own timezone, but everywhere.

By the way, before time change to winter/normal time it was 2 hours offset, but I guess that’s no surprise for you.

I would be really happy if anyone had a solution for this issue. If I find one, I’ll post it here of course.

2

Have you tried the simplemost thing?

var label = DateTime.Now.ToString();

You may find that this is correct, and if so, it’s presumably because the ToString method of DateTime actually considers the locale whereas the UTC time is intended to be uniform across the globe, not dependent on whatever some country calls winter or summer time.

Use the locale dependent time label for display to the user, but use the UTC timestamp for any computations or storage on a remote server (possibly in a different time zone).

3

Q are you sure the timezone on your web server is correct?

4

@CodeSmile

I tried implementing this, but since I am no coder I wasn’t able to make it work like this, at least not in the context of that script.
I’m working with Adventure Creator for Unity and meanwhile the dev of this plugin fortunately has fixed the problem. The solution includes some calculation, so it’s a bit more complicated than the original line.
If I had found the solution myself I would have posted it here, but I don’t want to steal his work - hope this is okay for users who might stumble upon this with a similar problem.

@bugfinders
Yeah, the web server wasn’t the problem. It happened in the local WebGL build as well as in the editor as well as on itch.io - everywhere the same.

5

OK, thats a bit odd, Im surprised as the system utc time should come from the server OS and not be dependant on any call from unity…

6

Hi!

My guess would be that it has something to do with the timezone configured in the system and/or browser. The offset by 1 hour suggests it is the daylight savings time not being applied correctly.

Can you add some logging to your code to inspect the current timezone? Is there is a difference between the timezone reported in browser and in the editor/standalone player?

using UnityEngine;
using System;

public class TimeZoneTest : MonoBehaviour
{
    // Start is called once before the first execution of Update after the MonoBehaviour is created
    void Start()
    {
        var localTimezone = TimeZoneInfo.Local;
        DateTime currentDate = DateTime.Now;

        Debug.Log($"Standard time name: {localTimezone.StandardName}");
        Debug.Log($"Daylight saving time name: {localTimezone.DaylightName}");

        Debug.Log($"Current date and time: {currentDate}");
        Debug.Log($"Is daylight saving time?: {localTimezone.IsDaylightSavingTime(currentDate)}");
        Debug.Log($"Universal Time: {TimeZoneInfo.ConvertTimeToUtc(currentDate)}");
        Debug.Log($"UTC offset: {localTimezone.GetUtcOffset(currentDate)}");
    }
}

At least the “Universal Time” should be the same between browser and editor.

7

Before the daylight savings time change, it was 2 hours difference. It happened in all browsers, so it was a general browser platform issue.

The dev explained to me that it was caused by the WebGL build saving to PlayerPrefs instead of what other platforms (like the windows build) do. I cannot explain / go into detail, but adding another playerprefs key with the timestamp was his solution that now works for me.

I’ll mark this post as solution since it is solved for me now. I actually posted here because I didn’t want to annoy the dev too much with my question/problem (especially since it seemed to be a general problem to me, not a specific one only happening in the context of that plugin), but they were so nice to look into it and were able to fix it. :slight_smile:

Depending on where you are located, you may never be able to reproduce this problem.

1 Like