91–100 of 437 posts
Earlier quoted context omitted.
Lots of people learn English because a large number of people speak it. Why should it not apply to Chinese or other often-used languages?
Thats exactly the point I’m making in my post. Glad you agree
Earlier quoted context omitted.
I have taken to writing 11 March 2021 or similar whenever possible. But sure, 2021-03-11 is also fine, when trying to save something machine readable. The US conventions are indeed horrendous.
Another great thing about 2021-03-11 is that, even putting aside its technical advantages, it is (probably) intuitively understandable to any literate person even if they have never seen it before and, most importantly, it is almost immune from confusion because (hopefully) nobody is insane enough to expect YYYY-DD-MM. YYYY-MM-DD both satisfies the American intuitive expectation of month coming before day, and the Wo…
While on the subject of time, could you Americans pretty please stop believing that the week starts on Sunday? It's just as wrong as your date format.
China and Japan have Sunday as the first day since the 4th and 8th century respectively: http://chartsbin.com/view/41671 . So presumably, you come from a Europe-centric view: http://chartsbin.com/view/41671
In their format settings, you have to pick a country and that determines the format of dates, time, numbers, and the unit system.
Of all the countries, none of them has the sane choice for all of the fields, namely: ISO 8601 for dates and times with 24h (no AM/PM), metric system (or SI, whatever), and dot as decimal separator.
You can have sane dates, but then you have AM/PM in the clock. You can have 24h clock, but then you have a comma as decimal separator, etc.
Can we add a country "Saneland" with the sensible options for all fields? cause that's where I want to be from. Saneland: the imaginary place where we use reasonable standards and things work.
Earlier quoted context omitted.
It's there: > This not only makes all of the dates look equally nice, but also, coupled with other quirks of this format, allows the files with the date in the name to be sorted just by the filename. My issue is with: > Simplified, the core date format looks like this: yyyy-mm-dd hh:mm:ss Here are the examples at https://en.wikipedia.org/wiki/ISO_8601 2021-02-26T06:22:59+00:00 2021-02-26T06:22:59Z 20210226T062259Z No…
I loath the T and Z characters, so respectively I use a single dash (Between the date and time) and no Z; for time I often leave in the colons (:). Example: 20210226-00:01:25 this presents the data in a format I can easily visually parse and also easily search for useful things in log files with. When parsing such a date I tend to throw out all of the characters, but the 'Zulu' or timezone at the end probably should…
The time is of course no problem but even with "20210226" standalone, I stumble and misread 10 and 22 before noticing that this doesn't parse. If there are more zeros and more 1's or 2's, it gets even worse.
I hate it that the migrations in Rails are numbers only. "db/migrate/20210218125920_add_new_column.rb" is simply not human parseable.
While on the subject of time, could you Americans pretty please stop believing that the week starts on Sunday? It's just as wrong as your date format.
Any choice is arbitrary. What is a week to the solar system? The only things that are real are days and years.
Earlier quoted context omitted.
Quite nifty and clean; I think this could play well with support for the duration (P-Y-M-D...) format in ISO 8601 that declares a positive offset. https://en.wikipedia.org/wiki/ISO_8601#Durations
Interesting, didn't know about that! Do you know of some canonical way of expressing negative offsets in spirit of ISO 8601? I don't seem to see those mentioned in the article...
As close to canonical as you can get.
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…
It's not just about years, and it's already explained in the article. When I see the date "02/03" or "02/03/2021", I can't tell if it means "March the 2nd" or "February the 3rd", because websites and software don't consistently detect (or even care) about my locale. But if the software show 2021-03-02, I unambiguously know which it is.
We weren't so globally connected just 20 years ago, so if you were in US, you were used to MM/DD format and if you were anywhere else, you were used to DD/MM format. It was all local.
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…
Earlier quoted context omitted.
I have taken to writing 11 March 2021 or similar whenever possible. But sure, 2021-03-11 is also fine, when trying to save something machine readable. The US conventions are indeed horrendous.
Another great thing about 2021-03-11 is that, even putting aside its technical advantages, it is (probably) intuitively understandable to any literate person even if they have never seen it before and, most importantly, it is almost immune from confusion because (hopefully) nobody is insane enough to expect YYYY-DD-MM. YYYY-MM-DD both satisfies the American intuitive expectation of month coming before day, and the Wo…