Tangentially related: I hate GNOME's approach at configuring formats. In their format settings, you have to pick a country and that determines the format of dates, time, numbers, and the unit system. Of all the countries, none of them has the sane choice for all of the fields, namely: ISO 8601 for dates and times with 24h (no AM/PM), metric system (or SI, whatever), and dot as decimal separator. You can have sane dat…
ISO 8601: a better date format
351–360 of 437 posts
Re: ISO 8601: a better date format
#352Tangentially related: I hate GNOME's approach at configuring formats. In their format settings, you have to pick a country and that determines the format of dates, time, numbers, and the unit system. Of all the countries, none of them has the sane choice for all of the fields, namely: ISO 8601 for dates and times with 24h (no AM/PM), metric system (or SI, whatever), and dot as decimal separator. You can have sane dat…
+1 for a new locale, equivalent to C but with UTF-8, ISO DATE, ISO paper, ...
Re: ISO 8601: a better date format
#353Earlier quoted context omitted.
> The US format is the only one that's retarded, though. I wonder how it started? A skim of the internets hasn’t enlightened me.
It’s a representation of how us Americans talk - we rarely say 26th of February and instead say February 26 - and if necessary tack on the year. It feels exceptionally awkward to say 26 February, thought saying “twenty twenty one February 26” sounds very strange, too. But people are very good at verbally saying different than is written.
Re: ISO 8601: a better date format
#354At the risk of nitpicking, I prefer RFC 3339, which is a profile of ISO 8601. ISO 8601 provides room for things you typically don't want, e.g. dropping time zone offsets. While I'm typing this I realise that I've never actually read the ISO 8601 spec, like probably most people here, because it's not free. I cannot even be sure it really exists.
> never actually read the ISO 8601 spec ... because it's not free I was very surprised to discover this. Why are they charging money for the specification of a date format? I would expect standards like these to be published in public domain.
Re: ISO 8601: a better date format
#355Earlier quoted context omitted.
Meters are "human scale". To say not is nonsense. And 3/2. Is that the future or the past? No way to know. Did you miss the meeting, or is it next week? "No one uses a decimeter"... What bubble do you live in? But please, lecture some more about cultures you don't understand.
I’ve never read anywhere on any product dimensions written in decimeter. Show me one and prove your point.
Re: ISO 8601: a better date format
#356Earlier quoted context omitted.
The alternate I like to use on forms and such when I know it's likely going to be read by a human is "DD Mon YYYY", e.g. 1 Feb 2021 This is a bit more human-readable and closer to commonly-used forms of dates while still being completely unambiguous.
> This is a bit more human-readable and closer to commonly-used forms of dates while still being completely unambiguous. A bit more human readable you say? So 1 фев 2021, 1 Lut 2021, or 2021 فبراير1 are readable to you? I don't know but to me that's just US-centric thinking all over again.
I was going to ragequit at you for copy+pasting something into google translate, as it's شُبَاط not فبراير.
but TIL, only in the Levant do we say شُبَاط apparently.
Re: ISO 8601: a better date format
#357The article is missing one of the best features of iso 8601: it‘s string form is naturally sortable. You don‘t need any specific logic for sorting, so e.g. your filesystem will automatically sort files correctly if you prefix them with a iso 8601 date.
Only true if you ignore timezones and DST (which most people do because it is unholy mess) or stick to UTC.
UTC just happens to be a good natural choice for eliminating timezones, but I've seen companies chose another tz as their standard.
Re: ISO 8601: a better date format
#358Earlier quoted context omitted.
Is their punishment to be forced to parse "009" with the C language's strtoul() library function for all eternity? (-:
What's the problem with strtoul? Just make sure to pass 10 as the third parameter, not 0.
Re: ISO 8601: a better date format
#359Earlier quoted context omitted.
There's a special place in hell for people that using variable length representations for time units that are meant to be consumed by machines. I think it's across the hall from the room for people who configure servers for anything besides UTC.
Where do you put the people who think that we should inflict leap seconds on UTC?
Re: ISO 8601: a better date format
#360A note from the front line. I actually use 8601 dates in a date-heavy consumer product ( https://clubman.app ) and it’s hands down the feature I most consistently get user feedback on. It’s always “Why are the dates all American format? Can you change them to English?” And then I try to patiently explain that they’re actually international format. People seem to have internalised that any date format they find slight…