14 ms·
I have a special hate for the native browser controls when it comes to date ordering. Given the us-centric nature of the web, most of the rest of the world need
by emn13 4y ago
I have a special hate for the native browser controls when it comes to date ordering. Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format. It's normal therefore to see dates in a format that's appropriate in context - a us news article might use a US format; others will use a different format that makes sense in context.
Yet that's not how browser controls work - browser controls for all major browsers always use the client's date formatting settings when displaying dates (once popped up it's usually obvious which is which). And that just makes them pretty much unusable; it means outside of the US you will have dates in text using 1 format, whereas browser controls use a different one. That's... completely unusable. How all three of the major browser manufacturers managed to agree on this particularly hostile design is beyond me.
- bmitc 4y ago> Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format. What is odd about it other than being different and not being immediately lexically sortable in file names? Edit: It's an honest question. People and context help determine what you're wanting out of a date, so I am curious what is viewed odd about the U.S. format aside from it being not what your country uses or what the ISO standard is,
- nemetroid 4y agoThe middle-endianness.
- bmitc 4y agoThat describes it, but what is odd? What I like about it is that it arranges things in order of importance/relevance in most situations. The month tells me the most important bucket, the day clarifies the particulars, and the year locks down the date but it is almost always known in the given context. In my opinion, there is the one true format for data formatting and text representation (the ISO standard), but each of the various permutations do have their use cases where they shine. For normal dates, all three components are needed, but it is usually nice to know the month, then the day, and then the year is there just to be clear. Knowing the day gives me little information until I have the month, whereas getting the month first gives me more information, where sometimes I can even ignore the day.
- cesarb 4y ago> What I like about it is that it arranges things in order of importance/relevance in most situations. The month tells me the most important bucket, [...] In my experience, the thing which is the most important/relevant in most situations is the day of month. People often say things like "dia 10" when asked when something is going to happen; that means in context the 10th of the current month if today is the 9th or earlier, or the 10th of the next month if today is the 11th or later. The month is added only when necessary, like "dia 10 de fevereiro" (just "dia 10" today would mean the 10th of January).
- Symbiote 4y agoAll this works in British English just the same as it works in Spanish etc. When are we back at work? On the second. Then go-live is on the fifth of March. (Normally 5 March or 5th March when written.)
- mannykannot 4y agoI am not persuaded that there is any hierarchy of importance here, let alone that there is a preferred one. Any wrong date is the wrong date.
- nemetroid 4y agoRegardless of whether it’s useful, middle-endianness itself is odd.
- tidenly 4y agoTruly a bizzare argument that only gets harder to understand every time I hear it. Whether the day, month or year is most important changes per every case. Are you telling me if you had file cabinets for the last 50 years, and you had to get a specific file Nov 1992, you would rather sort first and get all the files marked "November", and then sort through those 50 to get to the 1992 November? Surely one would reduce down to the year - 1992 - first, and then to the month. Same for alphabetical ordering, a data list ordered by logname-MMDDYYYY.log alphabetically wouldnt be chronological order - YYYYMMDD or DDMMYYYY would. Month is primary in some cases sure, but I think year and day endian are primary in many others - plus have the above sorting and ordering benefits.
- kzrdude 4y agoIt's "odd" for a person who is used to saying "third november" and not "november third", i.e the order is reversed even there. A spoken language full date format for me would be like "third november 2022". That, in either in english or in my native language. I don't know how circular this argument is (does the spoken form come from a written form of the date?). But this is what makes it odd, that in spoken form I, for example, am used to saying the date first but the "odd" date format writes the month first.
- bmitc 4y agoThat’s the type of thing I was looking for. Thanks. I’m curious about the circular reasoning as well, as the same would hold true for both preferences. Do you mind sharing what language you speak where the day is most often said first? It sometimes is said that way in English, but not as often as the other way around. It’s usually said that way when the day carries higher importance than normal. Like the 4th of July or something.
- kzrdude 4y agoSure, Swedish. I prefer day first in English as well as I understand it it's accepted and commonly used (British English). The languages I know how to say it in are all closely related to Swedish but they agree. And then Spanish uses day first too.
- int_19h 4y agoThis is the case for most Slavic languages.
- moritzwarhier 4y agoCan you elaborate on what you mean by date ordering? I suppose that the ordering of dates is independent of locale. The locale rules for the date format are simple: the DOM value property of the field is a string in YYYY-MM-DD format, independent of locale. The date display format and what the text input accepts depend on browser locale. Conversion happens automatically and the text input is shown in a way that indicates locale on desktop, least I remember (e.g. dots for European format, slashes for US). If a user enters "1.5.2011" in a browser with German locale, HTMLInputElement.value would be the string "2011-05-01" (invisible to the user). I honestly can't think of any better choices, the only thing missing is some attribute to eplicitly control display locale. Which is probably by design, as it would be abused to override system/browser locale and create confusion. I once replaced a Vue date picker library in a web app with native date inputs for UX reasons (e.g. typable dates, reliable visibility of the picker when fields are near window borders, mobile UI...) and users were reportedly happy with that. Admittedly, it was mainly a desktop app. So, long story short: the only problem I see here is the mobile modal date picker UX. And thankfully, it can be improved in the future because it's part of the OS and not controlled by the website.
- mellavora 4y ago> Can you elaborate on what you mean by date ordering? day/month/year month/day/year year/month/day year/day/month The order of the numbers an be problematic. For example, 01/01/01 could be 1 Jan 2001, Jan 1 2001, 01 1 jan, or 01 jan 1. Would rather not do the april fools example. Or the pi day example.
- deleted 4y ago[deleted]
- moritzwarhier 4y agoAll of this is thankfully resolved by the spec choice to stick to a specific ISO string format for the value property. You are talking about locale-dependent formats - which is why the value property of the input element conforms to ISO 8601 YYYY-MM-DD and guarantees that the values are predictably sortable. There is no other meaningful ordering of dates other than sorting chronologically. HTMLInputElement with type=date honestly does everything right given the constraints. As said, this post is a valid complaint about mobile native UI, no less no more.
- kzrdude 4y agoWhen does this problem come up? I don't see much combination of dates in the page's content in addition to simultaneously submitting a form with date input.