5 ms·

Displaying a date on a web page is so common that there should be an HTML tag for displaying a date in localised format.

lloydatkinson 7y ago
https://github.com/github/time-elements https://github.com/github/time-elements
- oftenwrong 7y ago
  I strongly approve!
- sli 7y ago
  My first thought reading the parent comment was indeed that WebComponents would be perfect for this. Thanks for the link.
onion2k 7y ago
Using <input type="date" value="2020-02-20" disabled=true /> should display in the correct format for the user's OS (there isn't a browser level setting to override it). It feels horrible using an input for display though.
- levosmetalo 7y ago
  Even that is not that simple. You have set your browser to US-English and you expect your date to be displayed that way in the application, but you see something completely different because your OS happens to be set to French.
  - Xelbair 7y ago
    solution is simple. Lets get rid of all date-time formats except the iso(YYY-MM-DD) one...
    - dec0dedab0de 7y ago
      I just imagined a dystopian world controlled by a malicious AI that outlaws everything that can't pass the modern turing tests.
    - LinuxBender 7y ago
      There are a myriad of debates in email threads about standardizing on ISO 8601. I would love to see it happen, but I would not hold my breath. People code date formats into their applications and db schemas and many other reasons. In most cases I have seen, people could have used epoch and then simply displayed the date based on the user preference.
    - patelpankaj 7y ago
      These differences exist because of the freedom given to everybody about their choice. So countries make their operating standard and citizens follow it. It is simple to think that this format would work but the people who are not familiar with this format will be completely lost with it. People who are not educated but somehow learnt to follow one format; ask them to learn a new format; it will be so complicated.
      - jiggawatts 7y ago
        This is like arguing that nobody should adopt the meter because each country has their local feet, yards, furlongs, cubits, els, steps, rods, lacters, and canas. I mean think about it: countries decide their units of measurements and their citizens follow it. It's freedom! Sigh... You're not even from the United States, so you should full well know how important standardisation is across country borders. There are literally only three countries that haven't adopted metric, zero that haven't adopted the standard 24 hour / 60 minute day, and only four that haven't adopted the Gregorian calendar[1]. So why is it so hard to accept the one consistent date format? Seriously? Why? Tell you what: If you can tell me which day the following date represents, I'll give you USD 100. Seriously. I'm not even kidding. 03/04/05 Go ahead. Guess. [1] https://en.wikipedia.org/wiki/Civil_calendar https://en.wikipedia.org/wiki/Civil_calendar
  - onion2k 7y ago
    You have set your browser to US-English... You haven't though because there isn't a locale setting in the browser.
mudlark 7y ago
Give as a ts and let the browser do the heavy lifting would be ideal. Ridiculous state of affairs.
joshka 7y ago
Kinda agree, but I'd phrase it a little differently. There exists a time element already[1]. I'd move that the browsers should allow users to change the display of this element on an element / page / session / computer basis. Often there are two or more timezones that matter for any time (e.g. event local time, user's local time, UTC). Often knowing all of these times instead of just one is useful. Rarely is just one of them at the choice of the website presenting the time useful. This is my use case, there are many more. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/time https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
jiggawatts 7y ago
This cannot ever work. Give it up. Only the ISO yyyy-mm-dd format is unambiguous. If a user sees some random date, such as 3/4/xxxx, they have absolutely no way to distinguish if this is in their format or not. If you're in the US, you might assume that this is in your backwards M/D/Y format, meaning it's April 3rd, and you'd be right much of the time. However, if you're outside the US, then there are two indistinguishable possibilities: It's a US server ignoring your time format, so this date represents April 3rd. OR It's a server correctly showing you a date in your preferred format, so it's actually the 4th of March. At a glance, these aren't distinguishable. I easily click through 200-500 pages a day! I'm not going to sit down and try to work out which of those hundreds of pages a day, and thousands of pages a week are designed for humans, or just Americans.
- PhantomGremlin 7y ago
  If a user sees some random date, such as 3/4/xxxx, they have absolutely no way to distinguish if this is in their format or not. If you're in the US, you might assume that this is in your backwards M/D/Y format, meaning it's April 3rd, and you'd be right much of the time. If I, in the US, see 3/4/xxxx, its meaning is March 4th, definitely not April 3rd. But the fact that you got your example wrong only proves your overall point that it's a mess!

lloydatkinson 7y ago

https://github.com/github/time-elements https://github.com/github/time-elements

oftenwrong 7y ago
I strongly approve!
sli 7y ago
My first thought reading the parent comment was indeed that WebComponents would be perfect for this. Thanks for the link.

onion2k 7y ago

Using <input type="date" value="2020-02-20" disabled=true /> should display in the correct format for the user's OS (there isn't a browser level setting to override it). It feels horrible using an input for display though.

levosmetalo 7y ago
Even that is not that simple. You have set your browser to US-English and you expect your date to be displayed that way in the application, but you see something completely different because your OS happens to be set to French.
- Xelbair 7y ago
  solution is simple. Lets get rid of all date-time formats except the iso(YYY-MM-DD) one...
  - dec0dedab0de 7y ago
    I just imagined a dystopian world controlled by a malicious AI that outlaws everything that can't pass the modern turing tests.
  - LinuxBender 7y ago
    There are a myriad of debates in email threads about standardizing on ISO 8601. I would love to see it happen, but I would not hold my breath. People code date formats into their applications and db schemas and many other reasons. In most cases I have seen, people could have used epoch and then simply displayed the date based on the user preference.
  - patelpankaj 7y ago
    These differences exist because of the freedom given to everybody about their choice. So countries make their operating standard and citizens follow it. It is simple to think that this format would work but the people who are not familiar with this format will be completely lost with it. People who are not educated but somehow learnt to follow one format; ask them to learn a new format; it will be so complicated.
    - jiggawatts 7y ago
      This is like arguing that nobody should adopt the meter because each country has their local feet, yards, furlongs, cubits, els, steps, rods, lacters, and canas. I mean think about it: countries decide their units of measurements and their citizens follow it. It's freedom! Sigh... You're not even from the United States, so you should full well know how important standardisation is across country borders. There are literally only three countries that haven't adopted metric, zero that haven't adopted the standard 24 hour / 60 minute day, and only four that haven't adopted the Gregorian calendar[1]. So why is it so hard to accept the one consistent date format? Seriously? Why? Tell you what: If you can tell me which day the following date represents, I'll give you USD 100. Seriously. I'm not even kidding. 03/04/05 Go ahead. Guess. [1] https://en.wikipedia.org/wiki/Civil_calendar https://en.wikipedia.org/wiki/Civil_calendar
- onion2k 7y ago
  You have set your browser to US-English... You haven't though because there isn't a locale setting in the browser.

mudlark 7y ago

Give as a ts and let the browser do the heavy lifting would be ideal. Ridiculous state of affairs.

joshka 7y ago

Kinda agree, but I'd phrase it a little differently. There exists a time element already[1]. I'd move that the browsers should allow users to change the display of this element on an element / page / session / computer basis. Often there are two or more timezones that matter for any time (e.g. event local time, user's local time, UTC). Often knowing all of these times instead of just one is useful. Rarely is just one of them at the choice of the website presenting the time useful. This is my use case, there are many more. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/time https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...

jiggawatts 7y ago

This cannot ever work. Give it up. Only the ISO yyyy-mm-dd format is unambiguous. If a user sees some random date, such as 3/4/xxxx, they have absolutely no way to distinguish if this is in their format or not. If you're in the US, you might assume that this is in your backwards M/D/Y format, meaning it's April 3rd, and you'd be right much of the time. However, if you're outside the US, then there are two indistinguishable possibilities: It's a US server ignoring your time format, so this date represents April 3rd. OR It's a server correctly showing you a date in your preferred format, so it's actually the 4th of March. At a glance, these aren't distinguishable. I easily click through 200-500 pages a day! I'm not going to sit down and try to work out which of those hundreds of pages a day, and thousands of pages a week are designed for humans, or just Americans.

PhantomGremlin 7y ago
If a user sees some random date, such as 3/4/xxxx, they have absolutely no way to distinguish if this is in their format or not. If you're in the US, you might assume that this is in your backwards M/D/Y format, meaning it's April 3rd, and you'd be right much of the time. If I, in the US, see 3/4/xxxx, its meaning is March 4th, definitely not April 3rd. But the fact that you got your example wrong only proves your overall point that it's a mess!