Hacker News Reader

Comment by nu11p01n73R | Hacker News Reader

Took some time to realise that "Available 9.25" meant 25th September. The box looked more like a disabled button.

They even change date formats within the same section of the website, so no consistency at all. They use a slash in their date "9/25" for a Beats offer at the bottom of https://www.apple.com/mac/

I agree. The faux-button is a pretty inexcusable piece of interaction design. It's like underlining for emphasis on the web. Don't do it.

Yes, American dates are confusing and illogical at the best of times, I wish America would standardise on the international ascending order date style of 25/09/2017.

I hope we'd all standardize on the opposite: 2017-09-25.. it sorts properly when used in file and document names :-)

And all on UTC, please. End this timezone and daylight saving nightmare.

Yes! If I were dictator of the universe, this would be my first (and possibly only) change.

I'd also like metric time, but abolishing timezones and daylight saving would be more than good enough.

Honestly, the 2017-09-25 format is the only way forward for automatic proper sorting of folder/files..etc.

and there is no ambiguity, does 6/7/2017 mean 6th July or 7th June?

Yeah, I thought about that as I was writing my comment and realized that's why I always write "back to front dates" with dashes instead of slashes. I think it's probably because I always use that format in filenames and slashes feel like a very bad idea there ;-)

Yes, it would be so great if there could be a standard for dates formatted this way. It would have to be called something awesome like ISO 8601! ;-)

That is definitely also my preferred format, everything just sorts naturally then. Not so in love with the 2017-09-25T12:00 format as it does not work for filenames on my OS.

ISO 8601 supports an alternative format without separators, like 20170925T1200.

Obligatory XKCD. https://xkcd.com/1179/

ISO8601 is very nice.

I love the tongue-in-cheek alt text.

Yes that’s a huge problem and I’ve seen a lot of misunderstands from it.

I always read that as 6th of the 7th, 2017.

I like American dates for sorting though :)

There definitely still is ambiguity if you're unfamiliar with the format. Show someone "2017-07-06" and they still might be unsure whether that's June or July.

I have never seen YYYY-DD-MM format, on the other hand, both DD/MM/YY and MM/DD/YY are equally common, that's why I always prefer YYYY-MM-DD format as it is the least ambiguous and most useful (sorting files etc., as other comments have mentioned). Feel free to prove me wrong though.

I work with non-techies. Most are totally unfamiliar with YYYY-MM-DD so weren't sure what a date that was ambiguous in that format was. I totally agree that usage of YYYY-DD-MM is rare (in my experience, anyway), but none of these formats fare particularly well when it comes to discoverability.

Have you ever been to any of Kazakhstan, Latvia, Nepal or Turkmenistan? https://en.wikipedia.org/wiki/Calendar_date#Gregorian.2C_yea...

I can assure you that Latvia does not use YYYY-DD-MM. Officially Latvia is using ISO 8601. https://en.wikipedia.org/wiki/ISO_8601#Usage

I’d update the Wikipedia article but don’t have time to go digging for official sources. Something you (or someone else with domain knowledge) could do?

I've been to Latvia many times in last few years, but haven't noticed YYYY-DD-MM format, maybe it's historical? It looks like DD.MM.YYYY was the most common format there (at least on posters).

Japan and Denmark use this format.

If you have enough examples, you can see which field goes over 12. In undocumented datasets, that's the only option.

That assumes that the dataset is consistent with itself.

Well, you gotta assume something ;)

And you're right. I've seen some pretty strange stuff.

Sometimes, when forced to use ancient enterprise data systems, desperate staff use abandoned fields for new purposes.

Funny, I never thought about that :) And coming from Denmark I would always have recommended the exact reverse.

And it can be extended down to arbitrary units.

2017-09-25

2017-09-25-0929

2017-09-25-09290000000000

That would be my dream too :)

> international ascending order date style of 25/09/2017

I don't believe that's an international style?

"Since 1996-05-01, the international format yyyy-mm-dd has become the official standard date format, but the handwritten form d. 'month name' yyyy is also accepted (see DIN 5008)."

(ISO8601)

Or just use an unambiguous format especially when writing normal copy. It would only take a few extra characters to write it as "25th Sep" or "Sep 25".

+1, I'm not sure why people make their dates needlessly ambiguous. Writing out an abbreviated month removes any potential confusion.

I'm a '2017-09-25' fan, myself :)

Given that I read from left to right, I mean.

argh! i can't believe people are still arguing about whether we should do MM/DD/YYY or DD/MM/YYYY or anything similar to that. here's how you should write a date that you are going to show to a user:

Jan 11 2016

if you accept that premise, it doesn't matter (much) what order you put the elements in, because none of them can be confused with any other. a word is a month, a one- or two-digit number is the day of the month, a four-digit number is the year.

i feel the same way about websites that expect me to input phone numbers, credit card numbers, social security numbers, etc without punctuation or spaces. why are you making this my problem? if your backend requires that, then strip out everything i typed that wasn't a digit and do your own formatting. geez.

That sounds a lot harder to localize, if local month names have different abbreviations.

A programmer's job is to make things easier for the user, not for himself. That's why we get paid the big bucks.

Don’t you mean 11. Jan 2016? ;)

that way would work fine, too. i can look at that and tell what date we are talking about at a glance.

the real problem is displaying both the month and the day of the month as one- or two-digit numbers, which leads to ambiguity. display the month as a three-character string, and the year as a four-digit number, and we are all on the same page again.

Actually it doesn’t, there’s standards for that.

YYYY-MM-DD

DD.MM.YYYY

MM/DD/YYYY

Notice the separators. Except for parts of Japan and Australia, these are international standards and used everywhere.

it's pretty obvious that, if those standards were being followed all the time, we wouldn't be having this conversation.

i am talking about an ad hoc, fairly simple thing one can do, if one is writing user-facing code. it's a rule i follow, and i offered it up as something other people might want to try as well.

I'm holding out for ISO8601 and UTC.

I am not sure if its the American date format or the way they choose to write them (with the . instead of - or /) made it confusing to me. On Indian website it is written "Available 26.9"

That's a great point; I get the appropriate date formats whether I look at the default site or the UK 'mirror'.

25/09/2017 would be no better than 9.25. Both are equally confusing.

ISO Dates would be better

The ISO standard is YYYY-MM-DD...

Reply on news.ycombinator.com