Make project manager's "last edited" field display using local time instead of UTC

[nobbele]

This also adds a core (Time) method to display a unix timestamp using the system timezone. Unsure if this should be added but I imagine this more general solution could be useful in games too?

Fixes #103808

[Grublady]

I'm a bit concerned about adding on to the (already quite long) list of Time methods that do very similar things.

Adding a get_local_datetime_string_from_unix_time method, which corresponds closely to the current get_datetime_string_from_unix_time, also begs the addition of other methods to keep the current parity. For example:

• get_date_string_from_unix_time would want get_local_date_string_from_unix_time
• get_time_string_from_unix_time would want get_local_time_string_from_unix_time
• and so on with each of the get_..._dict_from_unix_time methods.

And, adding any more dimensions of complexity in the future would further multiply the number of methods.

Perhaps the existing methods could have a local_time boolean parameter added instead?

Or, perhaps the Time methods could use a broader cleanup anyways—
Maybe a data type representing a moment in time (similar to Swift's Date) could work as an intermediary between the different representations (string, dict, Unix) so that we don't have to individually handle every permutation of get/from.

[aaronfranke]

When I designed the Time class, I intentionally kept it simple. It generally does not handle timezone conversions, it only handles the grunt work of converting whatever time you give it between formats. As @Grublady points out, a lot of these methods would need local versions. However, a local version itself is potentially not enough, people could ask for versions of the functions that involve working with any timezone, which would quickly explode into so many combinations.

Also, which part is local? This function expects a non-local input and gives a local output, but what about a function that goes the other way? (if both are local, or both are non-local, the current functions work fine). In this use case it's obvious, but how can you effectively communicate the local-ness to readers in all future use-cases and all functions?

This is why I don't think a new method should be added here. The call sites needing a local time can call OS::get_singleton()->get_time_zone_info(), add the offset, and then call the Time method.