[AdapterLuxon]: Getting error when using `pt-BR` locale and macro token `DD`

[genepaul]

[AdapterLuxon]: Getting error when using `pt-BR` locale and macro token `DD`

[flaviendelangle]

The expanded format of DD for the locale pt-BR is d de MMM de yyyy
Where de is not a format token but is not escaped either.

@alexfauquette for me the problem is that de looks a lot like a format, so it matches isTokenStartRegExp.

The only solution I see to support it would be to totally stop throwing when we have a an unknown token and instead add it as a separator.

The following diff works and does not cause any test to fail:

--- a/packages/x-date-pickers/src/internals/hooks/useField/useField.utils.ts
+++ b/packages/x-date-pickers/src/internals/hooks/useField/useField.utils.ts
@@ -20,16 +20,11 @@ import { getMonthsInYear } from '../../utils/date-utils';
 export const getDateSectionConfigFromFormatToken = <TDate>(
   utils: MuiPickersAdapter<TDate>,
   formatToken: string,
-): Pick<FieldSection, 'type' | 'contentType'> & { maxLength: number | undefined } => {
+): Pick<FieldSection, 'type' | 'contentType'> & { maxLength: number | undefined } | null => {
   const config = utils.formatTokenMap[formatToken];
 
   if (config == null) {
-    throw new Error(
-      [
-        `MUI: The token "${formatToken}" is not supported by the Date and Time Pickers.`,
-        'Please try using another token or open an issue on https://github.com/mui/mui-x/issues/new/choose if you think it should be supported.',
-      ].join('\n'),
-    );
+    return null
   }
 
   if (typeof config === 'string') {
@@ -413,7 +408,7 @@ export const changeSectionValueFormat = <TDate>(
   newFormat: string,
 ) => {
   if (process.env.NODE_ENV !== 'production') {
-    if (getDateSectionConfigFromFormatToken(utils, currentFormat).type === 'weekDay') {
+    if (getDateSectionConfigFromFormatToken(utils, currentFormat)?.type === 'weekDay') {
       throw new Error("changeSectionValueFormat doesn't support week day formats");
     }
   }
@@ -512,10 +507,13 @@ export const splitFormatIntoSections = <TDate>(
 
   const commitToken = (token: string) => {
     if (token === '') {
-      return null;
+      return true;
     }
 
     const sectionConfig = getDateSectionConfigFromFormatToken(utils, token);
+    if (sectionConfig == null) {
+      return false
+    }
 
     const hasLeadingZerosInFormat = doesSectionFormatHaveLeadingZeros(
       utils,
@@ -566,7 +564,7 @@ export const splitFormatIntoSections = <TDate>(
       modified: false,
     });
 
-    return null;
+    return true;
   };
 
   // Expand the provided format
@@ -611,7 +609,14 @@ export const splitFormatIntoSections = <TDate>(
         escapedPartOfCurrentChar?.end === i;
 
       if (!isEscapeBoundary) {
-        commitToken(currentTokenValue);
+        const success = commitToken(currentTokenValue);
+        if (!success) {
+          if (sections.length === 0) {
+            startSeparator += currentTokenValue;
+          } else {
+            sections[sections.length - 1].endSeparator += currentTokenValue;
+          }
+        }
 
         currentTokenValue = '';
         if (sections.length === 0) {

[alexfauquette]

The DD format is expended as

• d de MMM de yyyy for pt-BR
• d/MMM/yyyy for pt-PT

Their are two issue with d de MMM de yyyy format:

• On our side: we do not consider that de could be a token just because their is a token d (related to the issue about supporting format ddMMMYYYYY)
• On luxon side with DateTime.expandFormat('DD', { locale: 'pt-BR' })} returning d de MMM de yyyy because the de should be 'de'.
  For example, DateTime.fromISO('2014-08-06T13:07:04.054').toFormat('d de MMM de yyyy', { locale: 'pt-PT', }) returns 6 6e 08 6e 2014

[alexfauquette]

@flaviendelangle Your solution is to test if the token exist, and if no, put it into the separator. For now, it works without problem.

If we solve #10007 it will fail, because the parser will be able to detect the d as a token and we will get the 6 6e 08 6e 2014.

[flaviendelangle]

That's true...
And if we only do it if the character after is a space?
The amount of use cases not covered would get smaller and smaller.

[alexfauquette]

Just opened an issue in luxon to see how we can fix it: moment/luxon#1511

[flaviendelangle]

https://github.com/moment/luxon/blob/5ea19fb0cc80cddd03c6af21588b5ad7dcecaa35/src/datetime.js#L937

I fear that this is intented and that they won't be able to do anything about it dues to the nature of the parsing that relis on the Intl API.