The problem is that can be difficult to portably determine. One wishes POSIX had an API “give me IANA time zone name for current process” which would do the needful to work it out (read TZ environment variable, readlink /etc/localtime, whatever else might be necessary)… but no, you are left to do those steps yourself. And it works reasonably well if the TZ environment variable is set, but it most commonly isn’t; readlink of /etc/localtime works on macOS and some Linux distros… but others make /etc/localtime a regular file not a symlink, which makes it all a lot harder
And that’s POSIX. Then there’s Windows which is possibly the last platform to still use its own timezone database instead of IANA’s. Now, Unicode CLDR maintains a Windows-to-IANA mapping table… but you have to ship both that table, and maybe the IANA timezone DB too, with your app, and keep them updated
I really wish Microsoft would ship the IANA database with Windows, and the IANA-Windows mapping table too, and provide APIs to query them, and keep them updated with Windows update. The core Windows OS and existing Windows apps can keep on using the legacy Windows TZ database for backward compatibility, whereas portable apps could use IANA instead if they wish
> I really wish Microsoft would ship the IANA database with Windows, and the IANA-Windows mapping table too, and provide APIs to query them, and keep them updated with Windows update.
I think they have done exactly what you describe for several years at least:
That’s a .Net API, so not easily usable from native code. If they offered a C API instead, almost anything could feasibly use it.
Plus, from reading that doc, it sounds like it only works on Windows if you enable “App-Local ICU” mode, in which case the ICU DLL is added to your .Net app’s distributable package - which implies the info isn’t actually bundled with Windows itself
Consider Python’s zoneinfo standard library module-it provides access to IANA TZ database. On all platforms except Windows it uses the copy of the DB bundled with the OS and updated by the OS update mechanisms. On Windows, you have to install a PyPI module containing it. If Microsoft bundled it with the OS, with a C (not .Net) API, you wouldn’t have to do that-but Microsoft doesn’t, so you do
You conceivably need more than that. You need to know the location (NOT just the time zone) where it will occur, the time zone that location was in when the meeting was created, and the time zone that location is in when the meeting actually happens. The users' systems or whatever does final display need to know their own time zone(s), and how to convert.
Say, for a somewhat annoying-case example, you want to store a meeting date/time that's in the future, in January, in the city of New York, New York, USA, with remote participants elsewhere in New York state. Sometime in between when the calendar invite is created and the meeting the city of New York decides to change to be on permanent Daylight Savings Time, but the rest of New York state doesn't change. If you stored only the UTC time and "America/New York" you now have an ambiguous meeting date/time, since the "America/New York" time zone split and the city of NY is an hour off from the rest of NY for part of the year, and your remote participants could get the wrong time.
There's probably an even worse case involving the death of a Japanese emperor, since the "period" portion of a Japanese date is the imperial name of the emperor who ruled at that time, and that gets retroactively applied to dates between when the new emperor's coronation and when they took their new imperial name.
You still need the timezone name to map back to UTC, in case you want to make some types of computations, usually along the lines of "how long ago was this" and "remaining time until this thing happens".
You may argue that we can use local time to make the computations and be done with it, but during DST transitions, local time jumps so the number of actual seconds won't be consistent.
UTC only loses information.