Hacker News Reader

Comment by sbierwagen | Hacker News Reader

It's an American company, so they used the American date format.

Only the middle date is ambiguous anyway.

"This date format works for almost 61% of the year" isn't a great selling point.

This date format works for just as much of the year as DD/MM/YYYY though, and is just as ambiguous as the other format is if you don't know who the author is.

Sure. Which is why a non-ambiguous format would be preferred, like the ISO standard YYYY-MM-DD.

Which is also nice and sortable

Which is why if I have to write a date in non-big-endian order I try to spell the month out, e.g. 07 Dec 2022

The DD-MM-YYYY format is often used with dashes instead of slashes.

I actually don't think I've ever seen that one in the wild! I've seen 7-Dec-2022 which looks goofy to me but is at least unambiguous.

What does a full timestamp look like? For consistency I hope it goes all-in on being little-endian:

    ss:mm:HH DD-MM-YYYY

You’re describing DD-MMM-YYYY. What I’m saying is DD-MM-YYYY, like 7-12-2022 which is pretty common. Also, time is often shown after the date.

Day of month has no meaning without specifying the month, unless you specifically say “this month”.

So providing the day before the month does not provide any contextual advantage.

However, in most cases, the year is not necessary for contextual meaning.

So the alternatives are month + day or month + day and year.

If you don’t understand why something is done, but it’s been done for a long time, chances are that it evolved to be that way for a reason.

If something is arbitrarily dictated to replace an evolved system, there is most likely some information or practical purpose that is lost.

I now this is a bit beside the topic, but I basically know of two date formats: those with slashes in the, one should ignore because they have no meaning (because they are ambiguous) and an iso-like format which starts with yyyy and uses hyphens and I know I can rely on it to be yyyy-MM-dd so there is no risk of ambiguity (Unless of course someone uses yyyy-dd-MM but I don't think that format is a thing, it would be like writing a quarter past six as 15:06)

It works for the entire year though.

I work at an American company and we use a reasonable date format in technical writing anyway. It's not really an excuse.

Google is a global company and this is a message targeting VS code users who are global as well.

Good luck getting people to change the way they write dates, no matter how terrible it is.

ISO 8601 is pretty common amongst the engineers I've worked with. Odds are they didn't grow up with it unless they're from China or a handful of other countries that primarily use YYYYMMDD.

If you give people a good reason, they'll actually care. "Use YYYY-MM-DD as it allows us to sort by date in the filesystem" is a great reason. On the other hand, bickering about DD-MM-YYYY vs MM-DD-YYYY because "that's how it is in my country" just makes me roll my eyes.

I work at google and frequently collaborate with people from Germany, Australia, Japan, Taiwan, and the US. I always use YYYY-MM-DD in docs and emails to make sure everyone understands. It's still somewhat common to see mixups between the Americans and everyone else around MM/DD and DD/MM though.

Could you add this l10n issue to internal tracker? Thanks in advance. https://news.ycombinator.com/item?id=33890680

I found an existing issue but it's been open for many years. I'll see if I can bring attention to it again.

Well they are definitely American. Their reach is global, sure. That makes the rest of the world subject to their Americanness.

I work with lots of geographically dispersed and culturally diverse teams. The rule I always enforce is to spell (or abbreviate) the month in all dates. The other numbers tend to work themselves out.

Reply on news.ycombinator.com