DateTime localtime inconsistency

The hour of the local time is different when converted to a unix timestamp and then back to local time.
Expected behavior is that that the dates match.

print(DateTime.fromUnixTimestamp(DateTime.fromLocalTime(2025, 3, 10).UnixTimestamp):ToLocalTime())
returns

    ["Day"] = 10,
    ["Hour"] = 1,
    ["Millisecond"] = 0,
    ["Minute"] = 0,
    ["Month"] = 3,
    ["Second"] = 0,
    ["Year"] = 2025

I believe that this is related to daylight saving time. This is because the bug does not reproduce if the day is set to the 9th. I am in the US West timezone if that is necessary to reproduce.

1 Like

I believe that I’m experiencing the same problem. I’m writing code to get the current hour of the day in local time:

local currentHour = tick() % (60 * 60 * 24) / (60 * 60)

At the time of writing this, I get the following output (12:19 Eastern Daylight Time, as indicated by the timestamp):
image
We should get 12.32 to reflect that this is the 12th hour in EDT, not the 11th.

Running this same code except using os.time():
image
Which is the expected result for 4:20 PM UTC.

This issue is still occurring.

DateTime.fromLocalTime() and :ToLocalTime() are not aligned when converting to and from unix timestamps.

Hiya!

Tried this for myself and observed the same thing with a DateTime object during daylight savings + in a local zone that observes it. Let me raise this issue with engine folks and try to get a fix out.

Thanks for bringing it to our attention!

1 Like

Thanks for catching this! We’re aware of the issue and are looking into it. Right now, localTime in the DateTime API always uses your current local timezone offset, not the one that applied at the given date.
This means that if your area switches between PST and PDT (due to daylight saving), the API will always use whichever offset your system is currently under.
Supporting correct historical timezone offsets would require an API update to allow defined timezones, and we’ll share updates as progress is made.

2 Likes