[cvadict]

That is fine as long as the input / output is always in UTC... but at the end of the day you often want to communicate that timepoint to a human user (e.g. an appointment time, the time at which some event happened, etc.), which is when our stupid monkey brains expect the ascii string you are showing us to actually make sense in our specific locale (including all of the warts each of those particular timezones have, including leap second, DST, etc.)

[RHSeeger]

> That is fine as long as the input / output is always in UTC

But the title specifically say "from a UTC string", so it _is_ a UTC string, always.

> ascii string you are showing us to actually make sense in our specific locale

Locale and TZ are two completely separate things. You can use any locale in any TZ. You can use any locale in any location, too.

[GoblinSlayer]

That's a localization task, not timekeeping task.

[Macha]

It is not, if what the user expects to stay constant is their local calendar/wall clock time rather than the UTC instant. Which is usually the case. This is a transformation that needs late binding as DST and timezone rules can change, so it can't just be handled as a localisation transformation on input/output