Add format token for lowercased meridiem am/pm

[ediamin]

Right now we only have a format token for AM/PM. I think it is very common to use lowercased meridiem am/pm. It will be great if you add a new token for am/pm. Thanks.

[icambron]

There's no support for it in the Intl API, so I wouldn't be able to internationalize it. It's plausible that just lower casing whatever it produces would work, but I'd need to be convinced that's really legit across locales.

[benmccann]

I wonder if it would be better to use A in the 2.0 branch so that we can at least reserve a for future use in case the Intl API adds it or we come up with our own solution in the future

[networkimprov]

Have you considered just changing AM/PM to a.m./p.m. (lowercase with dots) which would distinguish this element from a timezone, e.g.

1:30 p.m. PST can't be confused with 13:30 PST

[icambron]

@networkimprov We could do that in the sense that we have hardcoded US English strings so we can override the Intl formatter in most cases and just decide to do it our own way. I'm loath to do that though:

1. It can't be optional, since we wouldn't be able to support the other options in other locales, where the Intl formatter has all the say. So we'd just have to globally change how that gets formatted. So we have to pick exactly one. And while I'm sympathetic to the request here, note that the Intl formatters for Chrome, Firefox, and Edge all use AM/PM (this may just be that CLDR uses that). Also (and again, we can only pick one), that does seem to be the majority choice for the US.
2. It wouldn't work in the admittedly rare cases that we decide to use other numbering systems or calendars and thus have to use the native Intl formatter (unless we post-process the formatter's output to add the dots back in, which I'm not going to do either), so that would be a weird inconsistency in which format got used depending on what seemingly unrelated options the user caller chose.
3. It wouldn't be consistent with other non-US EN locales that use meridiems and also don't put in dots (I checked Australia, for which Intl gives me am/pm), because of course we have to use the formatter for them.

Those can all be summarized as "yes, we can sort of do this, but it's better to be consistent with the Intl formatter". So I don't think that's going to happen. If the Intl formatter provided, like, a meridiemStyle option or something, it would be a no-brainer to just support that. But we're boxed in a bit.

Note that if you're using toLocaleString, you can use toLocaleParts instead and just post-process the meridiem part to your liking and then glue it back together. Probably ~10 lines of code. For the toFormat case, unfortunately, we don't have a toFormatParts so you'd have to be more creative.

[networkimprov]

OK, thanks for the detailed breakdown!