There is no universal standard for time zone abbreviations. You can review the list here, but even then there are some that are not listed or ambiguous.
For example, some people use HAST
for Hawaii, while others use HST
because they could care less about the Aleutian islands in Alaska (which is what the A
is supposed to represent).
Also, values like CST
could be "Central Standard Time" (USA), "China Standard Time", or "Cuba Standard Time". EST
could be "Eastern Standard Time" (USA), or "Eastern Standard Time" (Australia).
I could go on all day. The point is, you should only use time zone abbreviations when showing time to a human, and only when there is some other implied context like location. If you want one for those scenarios, you will need some conditional logic in your application, any you need to be careful to avoid making the false assumption that an offset can be directly translated to a time zone or a single abbreviation.
You might be able to come up with an abbreviation for a full IANA/Olson time zone, but you will need a TZDB implementation - which is not native in C on Windows. For more details, see this question and answer.
There are a few specifications such as RFC822 that use time zone abbreviations, but they only define a small handful of them, and are mostly fixated on the USA. They tend not to be included on anything more modern or having global impact.