I’m making a save game system in my game and I want it to keep track of the last time the player loaded the save.
Sounds simple enough, but the ‘Now’ node in the Blueprint system is returning the wrong time.
I tested it inside the editor, standalone game and packaged project. I even tried on a different project and a different computer. Still the same two-hour difference.
Am I doing something wrong?
I’m assuming that it’s getting a server time instead of local time.
Try this -
the subtract i’m using is a “Date Time - Timespan”
How you could implement this into your game, is to have players set their " time zone" in settings.
Then instead of using just the “2” “from hours” you would get their time difference, and set up the variable “timeDifference” to correctly show the time.
Actually no this is a bug. I take that back. What you need to do is grab the “UTC now” node instead of the now node. Epic got it backwards and made “Now” grab UTC time and “UTC now” grab local time.
So yeah, just replace your “now” with “utc now” and it should work.
Thank you for the feedback. What you are seeing is not the intended functionality. I have entered this as JIRA UE-5561 in our tracking software and our developers will be looking into it further.
The workaround TSpartanT mentioned above is the best option in the meantime.
Thank you for your comment.
I’ll use the UTC time node until it is fixed.
I’m revisiting this issue now and would like to clarify the behavior. Technically, what you are seeing is correct, but it is confusing and unintuitive.
As of changelist #2375426, the blueprint nodes for “As Time” and related methods will assume the timezone is unknown. The date time will be treated as UTC, but any references to the timezone in the printed time will be replaced with “Unknown”. “Unknown” won’t be apparent because none of the “As Time” related blueprint nodes exposes any way to override the style or time zone, yet. With this change, you will need to switch back to using “Now”.
The gist of it is that “Now” is giving you an FDateTime that will give you the same year, month, day, hours, minutes, and seconds as your wall’s calendar and clock. It has no concept of the time zone. When you convert that to a Unix timestamp, as “As Time” does, it’s now giving you the Unix timestamp for that date and time of day as if it were UTC. IE: At what Unix timestamp would a UTC calendar and clock show this date and time of day. “As Time” then takes the timezone and applies it. The end result is what your calendar and clock would show when a calendar and clock at UTC show the same as your own does, right now. In short, you’re getting double the UTC offset. I’d bet that the machine you tested on is at UTC - 2, which is why the result is a further 2 hours off from your local clock.
The blueprint nodes for “As Time” and related methods will no longer assume the local timezone, but instead will assume an “Unknown” timezone - it will print as if it were UTC, but any references to the timezone will specify “Unknown”. The end result is that using “Now” and “Utc Now” will give the results you expected, in short form. If they printed in longer form, you’d see the timezone listed as “Unknown”. Until the “As Time” family of blueprint nodes can have their style and time zone arguments exposed, this will help alleviate confusion.