Locale strings not expanded in `get` format
See original GitHub issueThis code:
arrow.get("Montag, 9. September 2019, 16:15-20:00", "dddd, D. MMMM YYYY", locale="de")
works perfectly in arrow
1.13.1, but in 1.15.2 I ge an Exception
t:
Failed to match 'dddd, D. MMMM YYYY' when parsing 'Montag, 9. September 2019, 16:15-20:00'
where the pattern is not expanded.
Am I doing something wrong?
Issue Analytics
- State:
- Created 4 years ago
- Comments:14 (11 by maintainers)
Top Results From Across the Web
Get Locale Short Date Format using javascript - Stack Overflow
Ultimately, I want to see a user-friendly format string based on the browser's locale (e.g. for 'en-AU' I want to display 'dd/mm/yyyy' )....
Read more >Locale (Java Platform SE 8 ) - Oracle Help Center
A map from single character keys to string values, indicating extensions apart from language identification. The extensions in Locale implement the semantics ...
Read more >Change Type Using Locale with Power Query
Change Type Using Locale with Power Query solves many issues when importing data with different date or currency formats.
Read more >locale - the Tcler's Wiki!
The locale string consists of a language code, an optional country code, and an optional system-specific code, each separated by "_". The country...
Read more >Language Tags and Locale Identifiers for the World Wide Web
It matches, for example, the language tag de-DE-1996 , but not the language tag de-Deva . The string de-*-DE is an extended language...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I should have it done within the next week or two (adding to documentation/testing included)
Yeah I think adding appropriate punctuation that may be possible in a datetime string to the regex word boundary could be an appropriate solution to this. Feel free to play around with regex101 to help fix this issue, it is an amazing tool for visualizing regular expressions.