DateTime.fromFormat & regex match failed once upgrade to latest version of Edge and Chrome

[shinnqy]

Describe the bug
Once upgrade to the latest version of edge and chrome. DateTime.fromFormat failed, even the output generated by itself.

When I looked into this. I find the regex match failed.

To Reproduce

Actual vs Expected behavior
A clear and concise description of what you expected to happen.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser: latest version of edge and chrome
• Luxon version: 3.2.1
• Your timezone: beijing/shanghai +8

Additional context
Add any other context about the problem here.

[shinnqy]

I think you also need to handle unicode 32. Why not using \s instead of \ ?

Because Luxon use literal value to generate Regex value instead of using \s. It will use unicode 8238 to match.

[tehamawirelessd4]

Same here. This was working:
const opts={locale: 'en-US', zone: 'local'}
result = DateTime.fromFormat(datetime, 'D tt', opts)

And now, it fails. There's an unprintable unicode character in the regex right before the AM/PM indicator. This makes the parse fail, returning invalid date with the same legacy date strings as last week. My legacy date strings look like this: '2/21/2023 11:01:28 PM'.

As a workaround, I now use:
result = DateTime.fromFormat(datetime, 'D hh:mm:ss a', opts)

Which does not put the unicode character into the regex

Have also confirmed this is not an issue in Safari

[dasa]

This may be fixed by #1369

[shinnqy]

@dasa Thanks for the info. This PR created 3 weeks ago. Would you please help review it and merge it? I see you are contributor.

[dasa]

I see you are contributor.

That just means I've had PRs merged in the past: https://github.com/moment/luxon/commits?author=dasa

I'm not able to merge any PRs myself.

[dave0783]

Any word on when this can be merged We are having this issue as well.

[joepwijnhoven]

+1

[geertjansen]

+1

[diesieben07]

#1369 has been merged. The next version of Luxon will treat non-breaking white-space equally when parsing macro-tokens like t.

[RonNabuurs]

Just confirmed that this is also an issue in safari.