Replace local-time format attribute with intl format attributes.

[dgraham]

An initial spike to see if we want to drop all the strftime code and just use the Intl.DateTimeFormat instead.

<time is="local-time" datetime="1970-01-01T00:00:00.000Z"
  weekday="short"
  year="numeric"
  month="short"
  day="numeric"
  hour="numeric"
  minute="2-digit"
  second="2-digit">
Jan 1 1970 (whatever we'd like the default non-Intl format to display)
</time>

Using strftime on the client doesn't improve the experience much. It's going to use the wrong date and time format for some large subset of users. Using Intl.DateTimeFormat displays the date and time properly for everyone, according to their browser or system preferences.

This element's attributes just allow the element to configure the js formatter instance accordingly.

Note that in browsers without Intl support, e.g. Safari, IE 9/10, whatever the server renders as the <time> element contents is displayed to the user. No js customization takes place in that case.

[josh]

This was my initial thought in #17.

This path definitely feels more forward looking. I doubt browsers will ever natively adopt strftime syntax. But hopefully Intl formatters do become wide spread.

Ideally we could 🔥 the entire strftime implementation?

[dgraham]

This will always display the month, as well as weekday, in the user's locale. Unless the rest of the site is also translated into their language, we end up with two different languages in the interface. Do we drop this element, use the locale, or leave it as-is with strftime?

[dgraham]

Another option is to translate the attribute values into a strftime format, like we did in #27, rather than feed the values directly into an Intl.DateTimeFormat instance.

[josh]

I still think this is a good idea.

I feel like the way we want to approach this for future extensibility is that our library is Intl capable, but only supports en-* locales for now.

Another option is to translate the attribute values into a strftime format

We'll need to do that for browsers that don't support Intl anyway.

[josh]

For a our "best locale" algorithm, we should parse any given "en-us", "en-gb", "fr-fr", "de-de" into the language and region. Then always replace the language with "en". So you might end up with "en-fr" or "en-de". "en-de" should give you english words with 24 hour times.

[josh]

Damn, changing the region doesn't seem to affect it.

I need to look at how the lang/region stuff is configured in the browser.

[josh]

Helpful sudo Intl reference

https://github.com/andyearnshaw/Intl.js/blob/master/locale-data/json/en-US.json
https://github.com/andyearnshaw/Intl.js/blob/master/locale-data/json/en-GB.json
https://github.com/andyearnshaw/Intl.js/blob/master/locale-data/json/de-DE.json

[dgraham]

@josh Which JavaScript design award would this function win?

[dgraham]

That last commit makes the mapping from the element's formatting values into strftime format strings a lot cleaner.

[dgraham]

Added support for Safari and refactored the date and time formatting into a couple smaller functions.