5 ms·
You cannot since it's missing time zone
by udidnmem 2y ago
You cannot since it's missing time zone
- RHSeeger 2y agoUTC is a timezone, though. Or am I misunderstanding what you're saying?
- cvadict 2y agoThat 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.
- jxjsndbxbd 2y agoUTC would be marked as +Z Without any marking, it could be anything
- loeg 2y agoThe article explicitly mentions UTC all over the place. It's UTC.
- DamonHD 2y agoNo '+'. Noon UTC is "12:00Z".
- nophunphil 2y agoOne 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 2y agoRFC 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.