[udidnmem]

You cannot since it's missing time zone

[RHSeeger]

UTC is a timezone, though. Or am I misunderstanding what you're saying?

[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

[jxjsndbxbd]

UTC would be marked as +Z

Without any marking, it could be anything

[loeg]

The article explicitly mentions UTC all over the place. It's UTC.

[DamonHD]

No '+'.

Noon UTC is "12:00Z".

[nophunphil]

One factor complicates things a bit: this is one way to encode that the timezone is UTC, but +00:00 is also commonly used for example.

RFC 3339 is nice for this reason. Always UTC and terminated with a Z.

[GoblinSlayer]

RFC 3339 isn't always UTC and doesn't mandate Z, in only removes some extra flexibility of ISO 8601, like comma separator or short syntax.