How can I get the date and wall time in the user’s timezone for an arbitrary UTC timestamp taking DST into account?
I’m building a web/desktop project in Godot that needs to store and retrieve UTC timestamps and display whatever the date and wall time was/will be at that timestamp given the user’s timezone.
For example, if the user’s current wall time is 8 PM and their timezone will go back an hour for DST in one hour then a timestamp that is +120 minutes from now should display 9 PM instead of 10 PM. Additionally, if that user views the same timestamp again several months later when their timezone has gone back an hour forward, the timestamp should continue to display as 10 PM since that was the wall time when it occurred.
Godot’s Time class states it doesn’t handle DST and its Time.get_time_zone_from_system() function only returns the current UTC offset which doesn’t help when the timestamp I’m trying to format may have been made during a different DST cycle. Since the project needs to run both in a web export and on desktop I also can’t rely on .NET or JavaScript library since that would only work in one export or the other.
I’m at a loss for how I can show an accurate wall time for a timestamp. Is there something I’ve overlooked, a plugin, or a workaround others have used to deal with this? All I can think to do is either ask the user to manually enter their DST schedule, find a free REST API that can handle conversions, or try to bake known schedules into the app but all of those have their own problems.
I did see that but I’m not sure that helps in this situation. The timestamps I need to format are going to be from the future and past but that method only shows whether the user is currently in DST and doesn’t indicate when the transition occurs or by how much. Without knowing that additional info, I’m not sure how to use the user’s current DST status to determine the offset for a date months in the past or future.
Well use some heuristics then. There’s certainly a list of countries and periods of year at which dst applies. Get user’s location, find it in that list and apply that hour accordingly.
You could as well do without it. It didn’t exist in the past and it probably won’t exist in the future.
I debated it but this project is a sort of time manager for game jams and is meant to have gameplay to help people manage their time so I need most of the features of a game engine already. To me, it made more sense to start with the engine and figure out the parts not inherent to it than starting with something like JS or Java and trying to pull together a half dozen libraries to add 3D rendering, plugin support, particles, etc.
I’m also planning to have this distributed through Itch and it just makes things easier that way.
That’s definitely an option I’m looking into if there is no way to do it natively in Godot. I was worried there wasn’t and it’s sounding like that’s the case. I was just hoping there was a built-in solution I missed.
IANA has a freely available database that Java and other languages use for their DST lookups. The only issue is it’s written in a custom format and very complex because countries have complex rules around DST (and for some it’s completely arbitrary when it happens) so the schema is difficult to parse.
I would just ignore it but the problem is this is a utility/game for managing time during game jams and there are quite a few jams that take place directly over DST transitions (especially the zero-hour jams that run exclusively during the transition periods for a country) so ignoring it would cause a lot of issues.
I’ll look into the IANA option and see if there’s maybe a way to compile one of the existing schema parsers into the engine directly as an extension or port one to GDScript.
Date/time management is an insanely tricky thing to get right. Just look at libraries like Noda Time or Joda Time. If someone could do it for Godot, it’d be incredible. But if you’re just after basic DST adjustments, then maybe you can make do with something simpler.
It’s kind of amusing that when programming the most basic things are simultaneously also some of the most complicated ones: text (see: Unicode and various writing systems), numbers (see: floating point) and time (see above).
Built in solution would require that IANA database to be included into the engine. Dragging that along wouldn’t really be a smart choice. If Java has it maybe you can run an utility on the server and let Godot remotely query it.
Yeah no I definitely get why they wouldn’t want to drag it into the core engine where 99% of use cases don’t need it but now they have to maintain it. Even Java has to make periodic releases to bump the version of the DB it includes, among other things. For compiling it in, I was thinking more along the lines of me personally forking the engine with it built-in.
If I can find a decent way to handle the IANA DB with GDScript, I might look into releasing an addon in case anyone else needs it. If that’s too much trouble, I’ll probably just have the user put in their DST schedule manually and maybe include a few that aren’t prone to changing very often for convenience.
The server option isn’t a bad idea but in my case I want to release this for free so hosting costs would become an issue but probably not a bad idea for others especially if you’re already going to be running servers for things like multiplayer.
