undefined | Better HN

0 pointscvadict1y ago0 comments

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.)

0 comments

RHSeeger1y ago

> 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.

GoblinSlayer1y ago

That's a localization task, not timekeeping task.

Macha1y ago

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

j / k navigate · click thread line to collapse