You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In Luxon timestamp formatting, we have the ability to provide the locale like the following:
en-US will be English language and US as the country es-ES will be Spanish language and Spain as the country es-US will be Spanish language and US as the country
Now, given we have the timestamp 2024-03-05T14:09:47Z, and when we applied the respective locales, below is the current output
en-US will be 3/5/2024, 2:09:42 PM UTC es-ES will be 5/3/2024, 14:06:32 UTC es-US will be 5/3/2024, 2:09:47 p. m. UTC
The issue lies with es-US. We know the language should be Spanish, so all language should be translated in Spanish format.. But the country is set to US. This means it should follow the mm/dd/yyyy` format right?
I'm expecting
es-US will be the following output: 3/5/2024 .......`
To Reproduce
Please share a minimal code example that triggers the problem:
Actual vs Expected behavior
A clear and concise description of what you expected to happen.
Given in the locale, the country is set to US i.e. en-US, es-US, then the date time format should be mm/dd/yyyy instead of using the language set in the locale.
Moreover I want to understand what the language-Country combination plays in luxon when interpreting timestamps?
Desktop (please complete the following information):
OS: [e.g. iOS] - NodeJs 14
Browser [e.g. Chrome 84, safari 14.0] NodeJs 14
Luxon version [e.g. 1.25.0] 3.4.4
Your timezone [e.g. "America/New_York"] "America/New_York" and "es-ES" locale
The text was updated successfully, but these errors were encountered:
DateTime#toLocaleString pretty much just calls Intl.DateTimeFormat#format. The actual format is implementation defined and may change between runtimes (different browsers) or even different versions.
Check the underlying platform by using Intl.DateTimeFormat#format directly and possibly file an issue at the corresponding platform if you feel like it is not behaving according to spec.
Moreover I want to understand what the language-Country combination plays in luxon when interpreting timestamps?
When formatting, it is as described above.
When parsing, macro tokens (for example DDDD) are expanded using Intl.DateTimeFormat#formatToParts and a dummy date time. The resulting output is then back-matched to single tokens, for example { type: "weekday", value: "Monday" } will be matched to EEE or EEEE. Those non-macro tokens are then used for parsing normally.
Describe the bug
In Luxon timestamp formatting, we have the ability to provide the locale like the following:
en-US
will be English language and US as the countryes-ES
will be Spanish language and Spain as the countryes-US
will be Spanish language and US as the countryNow, given we have the timestamp
2024-03-05T14:09:47Z
, and when we applied the respective locales, below is the current outputen-US
will be3/5/2024, 2:09:42 PM UTC
es-ES
will be5/3/2024, 14:06:32 UTC
es-US
will be5/3/2024, 2:09:47 p. m. UTC
The issue lies with
es-US
. We know the language should beSpanish, so all language should be translated in Spanish format.. But the country is set to
US. This means it should follow the
mm/dd/yyyy` format right?I'm expecting
es-US
will be the following output:To Reproduce
Please share a minimal code example that triggers the problem:
Actual vs Expected behavior
A clear and concise description of what you expected to happen.
Given in the locale, the country is set to US i.e.
en-US
,es-US
, then the date time format should bemm/dd/yyyy
instead of using the language set in the locale.Moreover I want to understand what the
language-Country
combination plays in luxon when interpreting timestamps?Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: