5 ms·
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
by cvadict 2y ago
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.)
- GoblinSlayer 2y agoThat's a localization task, not timekeeping task.
- Macha 2y agoIt 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
- RHSeeger 2y 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.