| 07:02 | <sffc> | Here are my slides on the non-binding Intl Era Month Code Stage 2 Update: https://docs.google.com/presentation/d/1wvJoRFa8nRjlYSHuVLpxx-wCfwt4H9NIw2fsGJ72gxs/edit#slide=id.p (CC hsivonen) |
| 07:59 | <hsivonen> | Thanks. I've noted slides 8 and 9 for Gecko patch review purposes. |
| 10:30 | <eemeli> | sffc: On slide 9 you have new Intl.DateTimeFormat('und-SA', ...), but AFAIK no runtime does anything with the region there. Is that intentional? |
| 10:33 | <eemeli> | Though Intl.Locale does maximise that to ar-Arab-SA. For a locale tag like that, that does feel like it'd be closer to what the user wanted in this case. |
| 10:40 | <eemeli> | Also, "Anno Minguo" is pretty apt. |
| 11:59 | <eemeli> | Actually, should we consider a new localeMatcher option value that did apply maximization to the selected locale? Or is that something that's technically already allowed with "best fit" locale matching? |
| 13:00 | <sffc> | It is intended for locale extension resolution, i.e. mapping u-ca-islamic to u-ca-islamic-umalqura. Some other region might map to islamic-tbla or islamic-civil, but this is an open question. (We should make sure the spec allows this) |
| 13:03 | <sffc> | I read that some countries are working on launching a satellite to observe the crescent, and presumably after that happens, there might be another reliably predictable islamic calendar, say islamic-satellit, that some regions might start using. |
| 13:20 | <eemeli> | I'm pretty sure that the spec does not currently support that, unless an implementation specifically includes und-SA in availableLocales, or with "best fit" matching matches that to something like ar-SA. |
| 13:21 | <sffc> | Acknowledged |
| 13:23 | <sffc> | I'll change the slide to ar-SA to avoid this question during the presentation |