<commit_before># Support matrix

Luxon uses a slew of new browser Intl capabilities to tackle some of the tricker parts of dates and times. This means that not everything works in every environment.

## What works everywhere

Fortunately, most of Luxon works in anything remotely recent. A non-exhaustive list:

 * Create DateTime instances in the local or UTC time zones
 * Parse and output known formats
 * Parse and output using ad-hoc English formats
 * All the transformations like `plus` and `minus`
 * All of `Duration` and `Interval`

## New capabilities and how they're used

Here are the areas that need help from newish browser capabilities:

 * **Basic internationalization**. Luxon doesn't have internationalized strings in its code; instead it relies on the hosts implementation of the Intl API. This includes the very handy [toLocaleString](../class/src/datetime.js~DateTime.html#instance-method-toLocaleString).
 * **Internationalized tokens**. Listing the months or weekdays of a locale and outputting or parsing ad-hoc formats in non-English locales requires that Luxon be able to programmatically introspect the results of an Intl call. It does this using Intl's [formatToParts](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts) method, which is a relatively recent addition in most browsers. So you could have the Intl API without having that.
 * **Zones**. Luxon's support of IANA zones works by abusing the Intl API. That means you have to have that API and that the API must support a reasonable list of time zones. Zones are in some platforms a recent addition

You can check whether your environment supports these capabilities using Luxon's `Info` class:

```js
Info.features() //=> { intl: true, intlTokens: true, zones: true }
```

## The matrix

Here's the level of support for these features in different environments:

| Area        | Chrome |  FF | IE   | Edge | Safari | Node         |
|-------------|--------|-----|------|------|--------|--------------|
| Intl        |    24+ | 29+ | 11+  | 12+  |    10+ | 0.11_ w/ICU† |
| Intl tokens |    56+ | 51+ | None | 15+‡ |    11+ | 8+ w/ICU     |
| Zones       |   24+† | 52+ | None | 15+‡ |    10+ | 6+           |

† This is an educated guess. I haven't tested this or found a definitive reference.

‡ Earlier versions may also support this, but I haven't been able to test them.

Notes:
 * "w/ICU" refers to providing Node with ICU data. See [here](https://github.com/nodejs/node/wiki/Intl) for more info
 * Safari 11 is still in tech preview as of Sept 2017
 * IE is terrible and it's weird that anyone uses it

## What happens if a feature isn't supported?

You shouldn't use features of Luxon on projects that might be run on environments that don't support those features. Luxon tries to degrade gracefully if you don't, though.

| Feature                             | Full support | No Intl at all                              | Intl but no formatToParts               | No IANA zone support |
|-------------------------------------|--------------|---------------------------------------------|-----------------------------------------|----------------------|
| Most things                         | OK           | OK                                          | OK                                      | OK                   |
| Explicit time zones                 | OK           | Invalid DateTime                            | OK                                      | Invalid DateTime     |
| `toLocaleString`                    | OK           | Native Date's `toString`                    | OK                                      | OK                   |
| `toFormat` in en-US                 | OK           | OK                                          | OK                                      | OK                   |
| `toFormat` in other locales         | OK           | Uses English                                | Uses English if uses localized strings  | OK                   |
| `fromString` in en-US               | OK           | OK                                          | OK                                      | OK                   |
| `fromString` in other locales       | OK           | Invalid DateTime if uses localized strings‡ | Uses English if uses localized strings‡ | OK                   |
| `Info.months`, etc in en-US         | OK           | OK                                          | OK                                      | OK                   |
| `Info.months`, etc in other locales | OK           | Uses English                                | Uses English                            | OK                   |

‡ This means that Luxon can't parse anything with a word in it like localized versions of "January" or "Tuesday". It's fine with numbers.

## Polyfills

There are a couple of different polyfills available.
<commit_msg>clean up matrix.md<commit_after># Support matrix

Luxon uses a slew of new browser Intl capabilities to tackle some of the tricker parts of dates and times. This means that not everything works in every environment.

## What works everywhere

Fortunately, most of Luxon works in anything remotely recent. A non-exhaustive list:

 * Create DateTime instances in the local or UTC time zones
 * Parse and output known formats
 * Parse and output using ad-hoc English formats
 * All the transformations like `plus` and `minus`
 * All of `Duration` and `Interval`

## New capabilities and how they're used

Here are the areas that need help from newish browser capabilities:

 * **Basic internationalization**. Luxon doesn't have internationalized strings in its code; instead it relies on the hosts implementation of the Intl API. This includes the very handy [toLocaleString](../class/src/datetime.js~DateTime.html#instance-method-toLocaleString).
 * **Internationalized tokens**. Listing the months or weekdays of a locale and outputting or parsing ad-hoc formats in non-English locales requires that Luxon be able to programmatically introspect the results of an Intl call. It does this using Intl's [formatToParts](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts) method, which is a relatively recent addition in most browsers. So you could have the Intl API without having that.
 * **Zones**. Luxon's support of IANA zones works by abusing the Intl API. That means you have to have that API and that the API must support a reasonable list of time zones. Zones are in some platforms a recent addition

You can check whether your environment supports these capabilities using Luxon's `Info` class:

```js
Info.features() //=> { intl: true, intlTokens: true, zones: true }
```

## The matrix

Here's the level of support for these features in different environments:

| Area        | Chrome | FF | IE   | Edge | Safari | Node        |
|-------------|--------|----|------|------|--------|-------------|
| Intl        |     24 | 29 | 11   |   12 |     10 | 0.11 w/ICU† |
| Intl tokens |     55 | 51 | None |   15 |     11 | 8 w/ICU     |
| Zones       |    24† | 52 | None |  15‡ |     10 | 6           |

† This is an educated guess. I haven't tested this or found a definitive reference.

‡ Earlier versions may also support this, but I haven't been able to test them.

Notes:
 * "w/ICU" refers to providing Node with ICU data. See [here](https://github.com/nodejs/node/wiki/Intl) for more info
 * Safari 11 is still in tech preview as of Sept 2017
 * IE is terrible and it's weird that anyone uses it

## What happens if a feature isn't supported?

You shouldn't use features of Luxon on projects that might be run on environments that don't support those features. Luxon tries to degrade gracefully if you don't, though.

| Feature                             | Full support | No Intl at all                              | Intl but no formatToParts                          | No IANA zone support |
|-------------------------------------|--------------|---------------------------------------------|----------------------------------------------------|----------------------|
| Most things                         | OK           | OK                                          | OK                                                 | OK                   |
| Explicit time zones                 | OK           | Invalid DateTime                            | OK                                                 | Invalid DateTime     |
| `toLocaleString`                    | OK           | Native Date's `toString`                    | OK                                                 | OK                   |
| `toFormat` in en-US                 | OK           | OK                                          | OK                                                 | OK                   |
| `toFormat` in other locales         | OK           | Uses English                                | Uses English if format contains localized strings† | OK                   |
| `fromString` in en-US               | OK           | OK                                          | OK                                                 | OK                   |
| `fromString` in other locales       | OK           | Invalid DateTime if uses localized strings‡ | Uses English if format contains localized strings† | OK                   |
| `Info.months`, etc in en-US         | OK           | OK                                          | OK                                                 | OK                   |
| `Info.months`, etc in other locales | OK           | Uses English                                | Uses English                                       | OK                   |

† This means that Luxon can't parse anything with a word in it like localized versions of "January" or "Tuesday". It's fine with numbers.

## Polyfills

There are a couple of different polyfills available.

{'fraction_non_alphanumeric': 0.10933734939759036, 'fraction_numerical': 0.007429718875502008, 'mean_word_length': 1.4686493184634448, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 77, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4389294', 'n_tokens_mistral': 2358, 'n_tokens_neox': 2139, 'n_words': 1052}