Live data from Hacker News

Freedom Clock

domsson.github.io

31–40 of 189 posts

Re: Freedom Clock

#31
post #17
post #3

I get it, it's really annoying that there are different formats. In fact I once nerfed a small database by importing a bunch dates from a csv in the wrong format. But honestly both formats (M/D/Y and D/M/Y) are wrong, as clear from the clock example: dates should be big-endian; Y/M/D.

They are both "wrong" compared to big-endian, but M/D/Y is by far the least logical of the three formats. M/D/Y should never be a default for any software without the user explicitly selecting it or specifying their country.

What do you mean by "wrong?" And why should logic trump practicality? Besides, rightness and wrongness are value judgments. They have nothing to do with logic.

M/D/Y seems to be the most practical because it reflects how dates are spoken in American English. It separates the date (month/day) from the year, which in many cases can be omitted, while also keeping the larger unit, the month, up front.

Re: Freedom Clock

#32

Europeans have access to multiple countries, cultures, and languages, yet still complain about imperial units, date formats, "soccer," SMS, and all of the many other ways in which the United States differs. It's another country. Stop being so insular.

...

Re: Freedom Clock

#33
post #3

I get it, it's really annoying that there are different formats. In fact I once nerfed a small database by importing a bunch dates from a csv in the wrong format. But honestly both formats (M/D/Y and D/M/Y) are wrong, as clear from the clock example: dates should be big-endian; Y/M/D.

I'd much rather have D/M/Y, since then data is ordered by relevance. If I'm seeing a full date, I probably care more about the day than the month, and more about the month than the year. This is just pure bikeshedding tho, both are infinitely better than M/D/Y

Re: Freedom Clock

#34
post #3

I get it, it's really annoying that there are different formats. In fact I once nerfed a small database by importing a bunch dates from a csv in the wrong format. But honestly both formats (M/D/Y and D/M/Y) are wrong, as clear from the clock example: dates should be big-endian; Y/M/D.

Iso8601 for the win!

2023-03-25=1995

Re: Freedom Clock

#35

Europeans have access to multiple countries, cultures, and languages, yet still complain about imperial units, date formats, "soccer," SMS, and all of the many other ways in which the United States differs. It's another country. Stop being so insular.

America’s insistence on weird date and unit formats has a negative effect on software and resources used all around the world.

Developers aren't using M/D/Y. This is a straw man.

Re: Freedom Clock

#36
I moved to the US from a country using metric system and different formats for things like date and currency. I don't really find the difference important at all and have no trouble switching between units and formats (my job requires me to exchange information with teams in Europe and Canada). I did find that for the sake of avoiding misunderstandings date should always start with the year. It's also good for sorting files and folders. Daylight savings time is the only thing I wish we didn't have in the US.

Re: Freedom Clock

#37
To play devil's advocate, the American format aligns with how (American's at least) speak the date "March 24th, 2022".

Re: Freedom Clock

#38
post #8
post #3

I get it, it's really annoying that there are different formats. In fact I once nerfed a small database by importing a bunch dates from a csv in the wrong format. But honestly both formats (M/D/Y and D/M/Y) are wrong, as clear from the clock example: dates should be big-endian; Y/M/D.

While I agree that big-endian dates are the best solution (if nothing else, because lexical sort puts it in the right order), I think little-endian at least makes sense. The middle-endian format is just absurd.

> lexical sort puts it in the right order

For a few thousand more years, sure!

Re: Freedom Clock

#39

Europeans have access to multiple countries, cultures, and languages, yet still complain about imperial units, date formats, "soccer," SMS, and all of the many other ways in which the United States differs. It's another country. Stop being so insular.

It's pretty silly when people complain about different tastes in subjective areas, such as music, architecture, pronunciation, food or other cultural differences. However, when it comes to methods of technical communication such as time formats or measurement units the complaints have little to do with subjective preferences, and more to do with real world consequences of maintaining unintuitive systems. Technical language should be clear, precise and uniform. That's what it's for. Insisting on maintaining different standards causes real headaches for everyone who has to deal with those systems, and sometimes can cause catastrophic errors. It has little to do with preference, and much more to do with practicality.

Re: Freedom Clock

#40
post #3

I get it, it's really annoying that there are different formats. In fact I once nerfed a small database by importing a bunch dates from a csv in the wrong format. But honestly both formats (M/D/Y and D/M/Y) are wrong, as clear from the clock example: dates should be big-endian; Y/M/D.

I'd much rather have D/M/Y, since then data is ordered by relevance. If I'm seeing a full date, I probably care more about the day than the month, and more about the month than the year. This is just pure bikeshedding tho, both are infinitely better than M/D/Y

I agree with you. Year is least likely to change, then month, so you can pay attention to D, and scan M/Y which I feel takes less attention than other formats
Post reply on HN