Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The tokens accepted by date-fns are different with what most languages and libraries support.
I focus here on YYYY and DD.
They all follow the specifications from the Unicode Consortium CLDR: http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns
Interpreted languages are mostly based on C function strftime() (so they are % based) since the interpreters are written in C. I guess strftime() predates the Unicode standard by several decades, that's why.
strftime()
Edit: somewhat related to #351
The text was updated successfully, but these errors were encountered:
UTR#35 for format (see #520) (#672)
format
c115a30
Merged, going to be fixed with the next release
Sorry, something went wrong.
@leshakoss Is this a breaking change? Should all localization files also be updated for this?
@mesqueeb yes it is and yes they should. I've updated the contribution guide some time ago. Here is the list of locales to be updated: https://github.com/date-fns/date-fns/blob/master/outdatedLocales.json
leshakoss
No branches or pull requests
The tokens accepted by date-fns are different with what most languages and libraries support.
I focus here on YYYY and DD.
Comparable:
They all follow the specifications from the Unicode Consortium CLDR: http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns
Not comparable:
Interpreted languages are mostly based on C function
strftime()
(so they are % based) since the interpreters are written in C. I guessstrftime()
predates the Unicode standard by several decades, that's why.Edit: somewhat related to #351
The text was updated successfully, but these errors were encountered: