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
Eventually we should allow the customization of dates just like how we do numbers now. Liquid has also a “date” command that allows reformatting of dates, and we can take heed from that and strftime.
Me:
strftime alternates between different forms of notation with quite arbitrary use of flags: %y as two-digit year, %Y as four-digit year, %B as name of month, %b as truncated name of month, %m, as zero-padded month digit, %-m as unpadded month digit. Specifying a Roman numeral for month (which is Continental European practice), or Japanese instead of Arabic numerals for date numbers, is going to take a lot more than strftime out of the box. twitter-cldr-rb also seems to have gone in a wrong-headedly inflexible direction with date specification. (I can't even tell if twitter-cldr-rb supports Roman numeral months at all.)
I see "alternative numeric symbols" are allowed through the modifiers O and E: %0m is an alternative numeric symbol for a month (which can be a Roman numeral, as confirmed in https://manpages.ubuntu.com/manpages/focal/man3/strftime.3.html ), and %EY is a locale-dependent representation of the year (which might be the regnal year—but which doesn't give us the alternation between numeric and Kanji regnal years).
Reading that, %Ey is an offest from a base year %EC, and that implies a regnal year (per https://stat.ethz.ch/R-manual/R-devel/library/base/html/strptime.html, E stands for "era", e.g. different religious calendar); but that spec still doesn't give numeric vs Kanji regnal year: %Oy is defined as offset from %C, in other words two-digit year in the century.
strftime is going to need a lot of extending to cope with East Asian dates, and we should try to find out whether anything of the sort has been attempted in East Asia.
I see twitter-cldr is based loosely on the Unicode CLDR values for dates:
In that spec, the regnal year is covered as G for the emperor and y for the year; but the CLDR spec does not allow alternation between different numbering systems at all. CLDR seems to be hardcoded to Arabic numerals, including notions of significant digits, and will need to be extended if we want it to alternate between Roman, Arabic, and Chinese numerals.
The text was updated successfully, but these errors were encountered:
From #138
@ronaldtse:
Me:
strftime alternates between different forms of notation with quite arbitrary use of flags: %y as two-digit year, %Y as four-digit year, %B as name of month, %b as truncated name of month, %m, as zero-padded month digit, %-m as unpadded month digit. Specifying a Roman numeral for month (which is Continental European practice), or Japanese instead of Arabic numerals for date numbers, is going to take a lot more than strftime out of the box. twitter-cldr-rb also seems to have gone in a wrong-headedly inflexible direction with date specification. (I can't even tell if twitter-cldr-rb supports Roman numeral months at all.)
https://metacpan.org/pod/POSIX::strftime::GNU
I see "alternative numeric symbols" are allowed through the modifiers O and E: %0m is an alternative numeric symbol for a month (which can be a Roman numeral, as confirmed in https://manpages.ubuntu.com/manpages/focal/man3/strftime.3.html ), and %EY is a locale-dependent representation of the year (which might be the regnal year—but which doesn't give us the alternation between numeric and Kanji regnal years).
https://pubs.opengroup.org/onlinepubs/7908799/xsh/strftime.html
Reading that, %Ey is an offest from a base year %EC, and that implies a regnal year (per https://stat.ethz.ch/R-manual/R-devel/library/base/html/strptime.html, E stands for "era", e.g. different religious calendar); but that spec still doesn't give numeric vs Kanji regnal year: %Oy is defined as offset from %C, in other words two-digit year in the century.
strftime is going to need a lot of extending to cope with East Asian dates, and we should try to find out whether anything of the sort has been attempted in East Asia.
I see twitter-cldr is based loosely on the Unicode CLDR values for dates:
https://unicode-org.github.io/icu/userguide/format_parse/datetime/
https://www.unicode.org/reports/tr35/tr35-dates.html#Contents
In that spec, the regnal year is covered as G for the emperor and y for the year; but the CLDR spec does not allow alternation between different numbering systems at all. CLDR seems to be hardcoded to Arabic numerals, including notions of significant digits, and will need to be extended if we want it to alternate between Roman, Arabic, and Chinese numerals.
The text was updated successfully, but these errors were encountered: