Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ISO 8601: a better date format

kirby.kevinson.org

Post reply on HN
Print view View original

271–280 of 437 posts

Re: ISO 8601: a better date format

#271

Post by systemvoltage »

alkonaut wrote: post #226
systemvoltage wrote: post #28

No one here is talking about practicality for non-software engineers which is probably 99.9% of the population. It might be fine for sorting and no one gives a shit about endianess. Common person would argue - why do they need to know the year first? Most people encounter dates in the same year, they already know we're in 2021 and it is not as important. Having to laboriously parse YYYY before getting to the most imp…

No. Every human likely encounters date sorting at some point. And feet and inches aren’t really any more human or natural than 4x5x2 dm or 40x50x20cm. Dividing by 10 isn’t more human either, but adding/removing zeroes or moving a decimal point is certainly easier for the human brain.

Is dm used widely wherever you’re located?

Re: ISO 8601: a better date format

#272

Post by mdip »

Date/Time is frequent topic[0] for me.

Generally speaking, a lot of these issues are knowing when it's appropriate to use what format. When displaying a date to a user, you do it in their configured local time, and in their configured date/time format. I don't think the author is advocating changing that behavior[1].

Where the problem comes in is "how you store date/time values". Normally, I don't find myself arguing as to the format. Generally speaking, people default to ISO-8601 for log file naming (many probably not realizing that's what they're doing -- aiming only for a naturally sortable list). The places I tend to store dates (databases) define how they're stored, otherwise. That doesn't mean a developer isn't going to store the date in server local/user local time (and often make discovering the reference time zone impossible). Please don't do this. Store in UTC.

I'm not sure why the author is so hung up about the ordering of the dates, but while I worked in telecom, I briefly had a boss that was really particular about that (I've worked for a few folks in the UK, only this first boss had hang-ups). The US ordering probably originates from the most common way dates are spoken in the US: "Januaray 17th". A year is less frequently necessary, but when it is, it's tacked on the end. I don't think anyone thinks the way we write dates is particular superior, it's just the way we've done it since we first learned about dates.

One thing I learned when I started working regularly with non-US folks. Never use numerical dates. Even if you write it in the format they are comfortable with, if there's any ambiguity, they're likely to assume you wrote it in the US format. I started writing/abbreviating month names. I ended up altering the written order, as well "17th of January or 17 Jan" because that particular first boss jokingly-non-joked about how obnoxious the other way was.

Everybody's got their tabs/spaces war, I guess!

[0] OK, so it's more of a pet peeve.

[1] While it would be nice if we all used the same date/time format in our day-to-day life, it's one of those things that I'll wager will never happen... and I'd argue that doing so would cause more problems than it would help.

Re: ISO 8601: a better date format

#273

Post by CyberRabbi »

richrichardsson wrote: post #128
CyberRabbi wrote: post #64

Earlier quoted context omitted.

Where’s the logical fallacy? More people natively speak Chinese than any other language in the world. If you want to maximize the exposure of your ideas, it’s only logical to render them in Chinese. It’s the same reason I prefer to distribute applications over the web. FYI: English has ~1100 million total speakers but only 318 millon native speakers, while Chinese has 918 million native speakers. https://www.visualca…

> More people natively speak Chinese than any other language in the world You've made the assumption that all Chinese people speak one language, which is a false assumption I'm afraid [1]. [1] https://en.wikipedia.org/wiki/Languages_of_China

> You've made the assumption that all Chinese people speak one language,

No I didn’t. I cited the fact that Chinese is the largest natively spoken language in the world, by an order of magnitude.

Re: ISO 8601: a better date format

#274

Post by CyberRabbi »

TeMPOraL wrote: post #137
CyberRabbi wrote: post #21

Earlier quoted context omitted.

Maybe we should also start speaking Chinese since it may not be a bad idea to use something a large number of people will easily understand. Edit: this is not sarcasm. It’s simple logic, unless there is something wrong with learning other languages.

I think we should. At the very least, our children should. That's why I'm planning on having my daughter learn Mandarin along with English - to prepare her for the shape of the economy she'll be living in.

I’m doing the same with my kids. Cheers.

Re: ISO 8601: a better date format

#275

Post by diggernet »

wongarsu wrote: post #179
SideburnsOfDoom wrote: post #55

Earlier quoted context omitted.

> I've never actually read the ISO 8601 spec, like probably most people here Indeed. The comprehensive Wikipedia article on ISO8601 is as far as we go https://en.wikipedia.org/wiki/ISO_8601 Thanks for pointing out rfc3339 - this appears to be the "useful part" of ISO8601 for data interchange. https://tools.ietf.org/html/rfc3339

Draft versions of the ISO standard are easy enough to find on the internet. But the Wikipedia article is excellent and covers just about everything.

Yes, and I've read the drafts of ISO 8601-1:2019 and 8601-2:2019. But can I rely on them? They were published in 2016. What has changed between then and the official release in 2019?

Also, neither RFC3339 nor Wikipedia discuss features like open-ended time intervals. They are in the draft, but did they make the final cut? And in what form? No idea...

The closest I've found to "official" documentation of the 2019 update is a short summary of the changes, hosted by Library of Congress[1]. Which is nice to have, but I sure wish the real standard was public.

[1]https://www.loc.gov/standards/datetime/

Re: ISO 8601: a better date format

#276

Post by CyberRabbi »

ginko wrote: post #223
CyberRabbi wrote: post #64

Earlier quoted context omitted.

Where’s the logical fallacy? More people natively speak Chinese than any other language in the world. If you want to maximize the exposure of your ideas, it’s only logical to render them in Chinese. It’s the same reason I prefer to distribute applications over the web. FYI: English has ~1100 million total speakers but only 318 millon native speakers, while Chinese has 918 million native speakers. https://www.visualca…

>English has ~1100 million total speakers but only 318 millon native speakers, while Chinese has 918 million native speakers Why would that matter? Arguably the ideal lingua franca should have no native speakers at all as those have an unfair advantage.

> Why would that matter? Arguably the ideal lingua franca should have no native speakers at all as those have an unfair advantage.

I share your vision of an explicitly taught universal language which gives no group or individual an unfair advantage. We obviously need more equality in the world.

From the perspective of trying to maximize how many people with whom you are able to communicate, however, on a practical basis it matters little whether or not they are native speakers.

Re: ISO 8601: a better date format

#277

Post by andy-x »

tpetry wrote: post #17

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

Re: ISO 8601: a better date format

#278

Post by valbaca »

valenterry wrote: post #87

ISO 8601 contains durations and time intervals which are totally undervalued! ( https://en.wikipedia.org/wiki/ISO_8601#Time_intervals ) E.g.: 2021-05-01T12:00:00Z/P2H They are so convenient. Ever stored a tuple of two datetimes to model a time interval? E.g. a meeting that takes place on 2021-05-01T12:00:00Z and takes two hours? Don't! Instead, store it as an interval: "2021-05-01T12:00:00Z/P2H" Or are you creating a…

100% agree that it's undervalued.

Was just in a software design meeting where they were trying to figure out how to represent exactly this: a time interval.

I had to repeat "Just read ISO 8601 and use it" like a dozen times.

"Bu-bu-but what if we want to represent a recurring..."

READ IT. AND USE IT.

Re: ISO 8601: a better date format

#279

Post by pimlottc »

qayxc wrote: post #227
pimlottc wrote: post #52

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

That's true, but as I said, I just use this in certain human-read contexts, e.g. paper forms. Which in my part of the word are normally in English.

Re: ISO 8601: a better date format

#280

Post by diggernet »

em500 wrote: post #73

Free versions of the actual specs: https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i... https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i... Or https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en The ISO8601 yyyy-mm-dd format is fine and intuitive. What trips people up all the time is the ISO8601 yyyy-www-d format (year-week-weekday)[1]. People who know it well can appreciate the benefits…

Those two LoC links are for the 2016 draft of the 2019 specification. Hard to say how much it varies. And the ISO link only lets you see the definition of terms and symbols. Actual syntax details are all locked up.

https://www.loc.gov/standards/datetime/ seems to be a usable summary of the 2019 spec, though being just a summary means it probably excludes discussion of finer details and considerations which might be important at times.

Post reply on HN