Thanks to Jesse_b for finding this Stack Overflow Q/A:
TL;DR WSL Dynamically generates a fake timezone info file at
/usr/share/zoneinfo/Msft/localtime that in hard linked to
/etc/localtime. The Msft file uses the made up names
STD, and they stand for no specific timezone.
What is actually going on is WSL attempts to match your Windows timezone in Linux. This is a non-trivial mapping, as seen here (discussion). So rather than trying to hit a constantly moving target, what I believe WSL does is use the Windows API to get the Windows Timezone info, and based off of that information, it dynamically generates a timezone info file.
I believe that
wslhost (specifically code in
C:\Windows\System32\lxss\LxssManager.dll) does this inspection on your current timezone in Windows, and writes to the the
/usr/share/zoneinfo/Msft/localtime file. This is why when the timezone in Windows changes, you see the affect in an already running WSL instantly. But since there is no perfect mapping from Windows timezones to Linux or POSIX timezones,
wslhost probably just wings the name, and that's where the DST comes into play.
Update: Actually, I think it just says "DST" if you are in Daylight Saving Zone timezone, and "STD" for non DST timezone (Standard I assume).
So the answer to "What timezone does DST stand for" is none, and any Linux program that will attempt to match
/etc/localtime to a timezone file in
/usr/share/zoneinfo (via readlink or just searching), will only every get "Msft/localtime" as an answer. A "Technically accurate, but totally useless" answer.
The Windows 19H1 (1903) update, scheduled for final release in May 2019, resolves this issue and WSL distributions will report a conventional time zone where possible:
Until the final public release, the new version is already available through the Windows Insider programme, so if you have an active issue caused by the zone tag it is possible to work around it. You don't need to do anything to activate it or have the new time zone applied.