Great point. Thanks. I wish I had thought of that. I could easily use that in this macro, and in any other macros I write in the future.
I wonder how in the world they determine that. Time zones are geographical and political. Sometimes they split states or provinces, or follow rivers. Does macOS do some sort of geo-location to determine this string? I count at least 15 US states where the time zones splits down the middle of the state.
You specify your location at system setup, and that's what it uses. The current location is stored in the /etc/localtime link:
$ ls -l /etc/localtime
lrwxr-xr-x 1 root wheel 45 Nov 24 09:55 /etc/localtime -> /var/db/timezone/zoneinfo/America/Los_Angeles
˙
That, in turn, is set during setup by offering choices from /usr/share/zoneinfo. The USA info, for instance, is in /usr/share/zoneinfo/us. And as seen above in the link, /var/db/timezone/zoneinfo/America/ is the folder with all the detailed locations. Open that up, and you'll see tons of files (149 in America).
-rob.
Take a look in /usr/share/zoneinfo. I assume the information in there is updated as needed by Apple as part of routine updates. If I remember rightly, when you set up MacOS, you specify your timezone location (e.g. London - United Kingdom or whatever) and from there it can find all it needs from the zoneinfo files.
Edited to add: - Dang, beaten to it by Rob whilst I was typing my answer 
"You stay in Wonderland, and I show you how deep the rabbit hole goes." - The Matrix.
If you read this post, you will be going deep into the rabbit hole. You can follow my train of thought as I plumb deep into time zone issues.
Maybe I did specify my time zone when I installed macOS on my new M3 iMac a few weeks ago. (Or maybe macOS loaded it from the iCloud where it could also be stored in my iCloud data.) Indeed, my localtime file on my Mac does point to a city name in my province, although it's the wrong city by about 500 miles. Whenever macOS forces me to say that I'm in a city 500 miles away from where I live, I feel offended. Why doesn't it let me pick my city which contains over a million people? Probably because it doesn't need to list every city in the same time zone since most cities in the same time zone contain the same rules for DST.
So that got me examining the contents of the "/var/db/timezone/zoneinfo/America/" file very, very closely. And I noticed that there were some towns in this file that consisted of only a few hundred people. Why would this file contain towns of a few hundred people but not cities of millions? I think I have the answer now... many of those cities in that file have anomalous rules regarding the adoption of DST. And this is important because if macOS doesn't know which city you live in, (or at least the name of a large city in the same Time Zone as you) it wouldn't implement DST correctly for you.
The US has one thing going for it in terms of DST. Nearly every continental US state observes DST. The one exception is Arizona, and to make matters worse there, roughly half of Arizona observes DST and the other half does not. To make matters worse, I can't find any city in the non-DST portion of Arizona that's in "/var/db/timezone/zoneinfo/America/". This means if you live in the Navaho nation, you will have to lie to macOS about the state you are in if you want the correct time on your Mac year round. <---!!!
Canada has it worse than the US. There are (roughly) dozens of Canadian cities that differ with their province on the DST issue. Surprisingly, quite a few of these small cities (or their neighbours) are listed in /var/db/timezone/zoneinfo/America/. For example, there's Dawson Creek, Creston, and Coral Harbour which have different rules for DST than the province they are located in. So now we know why they are in that file. I always felt cheated when my city of over a million people is not listed in there, but several small towns of 1,000 people are listed there. Now we know why, it's for implementing DST.
But I just had a horrible insight... privacy and security. Many of the entries in /var/db/timezone/zoneinfo/America/ indicate towns of under 1000 people. Knowing which of these locations you are in could give a bad actor tremendous insight into your location and maybe your identity. My first fear was that Javascript may let you fetch this tz information, and that could be sent back to the host website and tell them if you live in one of the small towns listed in /var/db/timezone/zoneinfo/America/. However from what I can see, the only access Javascript has to your timezone data is GMTOFFSET(). That's not a lot of information, since millions of other people live in the same timezone, but if the website knows you are in Arizona (probably not hard to do) and then the website notices that your IP address has changed its clock during a DST transition, then it has narrowed your location down to the Navaho Nation. To me, that's a security problem. In Canada it's probably worse, because there are quite a few small towns that are in a large territory but don't have the same DST setting as their province. So your IP address will generally give away what province you live in, and your GMTOFFSET() changing during a DST transition will tell the website that you live in one of a handful of small towns.
From what I read online, there are discussions about modifying the HTTP protocol to include the time zone information from the client side. In my opinion, that wouldn't be a problem for a big city like Los Angeles, but for a small town like Creston, that would be a privacy DISASTER, as every web server would have the identity of the client down to a narrow window of a few hundred residents. And as far as I can tell, the time zone in the HTTP header could even be passed through proxy servers and possibly VPNs. VPNs are focussed on hiding IP addresses, not hiding the contents of the HTTP protocol.
---RABBIT HOLE WARNING---
CORRECTION: I've just learned there are Javascript libraries (500kb in size!) which CAN return your "IANA Timezone" string...
var tz = jstz.determine();
tz.name();
'Europe/Berlin'
Now I'm scared. I wouldn't be scared if I lived in or near Berlin, which probably has a very large population, but if the function returned, "Americas/Yakutat" then suddenly my privacy is out the window. There are 146 cities in /var/db/timezone/zoneinfo/America/ and dozens of them seem to be towns with a population of a few hundred. Remember, not even a VPN will block the execution of Javascript, so that means if you live in one of the small towns listed in that file, your privacy is nearly zero. If I lived in one of those towns, I would change my location to a different city, but then I might lose my correct DST status (or my state/province) in macOS.
To make it more clear, I think there's one town in that list (or should be in that list) with a population of 8. Just 8 people. If someone from that town used a web browser to visit a website that used the above Javascript to determine your IANA time zone string, the website would have your identity narrowed down to 8 people, out of 8 billion people, even if you are using a secure VPN. Is that a privacy problem?
I have moved this discussion to a new Q&A topic and away from the See upcoming global rocket launches Macro Library topic.