Live data from Hacker News

Freedom Clock

domsson.github.io

41–50 of 189 posts

Re: Freedom Clock

#42
One thing I've come to learn is that American formats are human-friendly rather than machine-friendly.

Our date system is like the Fahrenheit system; it works well when thinking like a human.

in Fahrenheit, you just think of it in terms of 50 being the middle, "not cold and not hot". Then you understand 80 is high warm, closing in on hot, etc.

Similarly for our date system, we lead with names and important information rather than numbers. We're not feeding a number into a machine, we're speaking to humans.

Consider any other Label. You don't say "25th Apartment", you say "Apartment 25", "Unit 25", "P.O. Box 25"

Here we are on March 25. The year comes last because it's least important.

Re: Freedom Clock

#44

Earlier quoted context omitted.

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.

Developers? Maybe but even if we accept that all developers pay close attention to their date formats to avoid misinterpretation errors, others who produce work within the developers workflow are certainly not doing so.

Re: Freedom Clock

#45

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.

...

There are more factors of 12 than of 10. This makes some imperial units more practical for certain types of things that involve mental math or quick calculations. Fahrenheit is higher resolution than Celsius for weather/climate measurements.

Re: Freedom Clock

#47
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.

AD > BC(E) & 2 BC(E) is before 1 BC(E)

Re: Freedom Clock

#48

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 la…

It's okay if there are differences. Arab-speaking countries use RTL, which causes huge issues everywhere. We don't tell them to change their language, we just adapt to it. Software developers are not using M/D/Y anyway, and everyone else who deals with international business should already understand the difference. When I see a non-American date, I assume D/M/Y. It shouldn't be that hard to expect supposedly cosmopolitan Europeans to do the same.

Re: Freedom Clock

#50
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 say whatever floats your boat. Which I guess could be pound-force (lbf).
Post reply on HN