Non-Gregorian calendars inside moment.js

[ebraminio]

MediaWiki's date formatter can easily generates non-Gregorian calendars output.

This is a copy of the related parts of the documentation:

Non-Gregorian calendars
Islamic
xmj	Day of the month
xmF	Full month name
xmn	Month index
xmY	Full year
Iranian (Jalaly)
xij	Day of the month
xiF	Full month name
xin	Month index
xiY	Full year
xiy	2-digit year
Hebrew
xjj	Day of the month
xjF	Full month name
xjt	Number of days in month
xjx	Genitive form of the month name
xjn	Month number
xjY	Full year
Thai solar
xkY	Full year
Minguo/Juche year
xoY	Full year
Japanese nengo
xtY	Full year

With considering this and an example calendar algorithm from MediaWiki, this is my proposal:

• Define a separate folder/script inside moment.js project for actual calendar algorithm implementation (xij, xiF, . . .) but don't include that on moment.js core
• Original modules of extension calendars should just include the English translation and locales modules which handle the translation of needed calendars for a locale. A fallback to English (which provided by the algorithm itself) should be done also when translation is not available on a specific locale module
• Locale module should define their default date format with their related calendars
• Similar to MediaWiki date format convention, what available on above table (or same moment-jalaali?)

With this design, using Iranian calendar on English and Gregorian calendar on Persian for example [both use-cases are important] would be easy.

I think if we decide about a design, implementing the needed change will be easier.

globalize also has support of Persian calendar for example.

Thank you and sorry about spell/grammar/facts errors available

[ichernev]

OK, so you're suggesting

• add support for plug-in-able calendar systems
• add support for plug-in-able format tokens

I have a few questions:

• don't we also need plug-in-able parsing tokens
• do you expect to add special functions for those calendars (like getJapaneseYear) or we can just use an extensible get/set interface. The names can be the x-names from above, although I think there should be a longer, more readable version
• what about local, utc and zoned version of those. Is there anything special to know?

extensible get/set

moment.registerUnit(name, getter, setter)

• name is year (built-in), xmj (plug-in), etc
• getter = function(moment, name) {} returning the value of the unit for a given moment object. name is given to allow reuse
• setter = function(moment, value, name) {} setting the value of the unit for the given moment object. name is given to allow reuse

extensible parsing tokens

moment.registerParseToken(token_regex, string_regex[, loose_string_regex], handler)

• token_regex is like xmj
• string_regex is a regex used to match in strict parsing, for example\d{3}
• loose_string_regex is a regex to use in non-strict parsing. Defaults to string_regex
• handler = function(token, parsedInput, config) record a parsed token into config, for example (for all /xm./ tokens)

handler = function(token, parsedInput, config) {
  config._xm[token.charAt(2)] = parseInt(parsedInput, 10)
}

extensible converters (calendars)

moment.registerConverter(converter, inputFmt, outputFmt)

• converter = function(config) {} converters the data stored in config from the handler to something understandable. Right now moment supports isoweek/isoWeekDay/isoWeekYear, week/weekDay/weekYear, year/dayOfYear, and day/month/year.
• inputFmt -- the name of the format from which this is converting
• outputFmt -- the name of the format to which this is converting

For example {inputFmt: 'xm', outputFmt: 'dayOfYear'} (but I really don't like the name xm).

input/output formats would be used to define in which orders should the converters run, and would enable sharing of code in the converter. We might need to also record which converters need to run based on the format tokens used, so that we don't run 100 unused converters. We can also get rid of them and depend on the registration order (run last registered first).

extensible formatting tokens

moment.registerFormatToken(token, formatter)

• token is like MM
• formatter = function(moment, token) {} returns the string to be displayed

@icambron any thoughts? I think this is a good candidate for the 3.0 release. It would need moderate refactoring throughout the code, but it shouldn't be too hard.

[ebraminio]

Excellent!

• Yes, I guess
• I don't think
• No. I don't remember anything like this on MediaWiki at least

I like a transparent solution where a small project won't need to care about local calendars but would automatically get a good localized UI but also a more advance project can have options for doing different things. On libicu every locale has a default calendar, Persian (Iranian) calendar for fa and this. Instead complete transparency, another solution could be providing some tokens for locale preferred calendars (alias to their real token but independent from exact calendar).

+1

[robin-karlsson]

+1

[Nate-Wilkins]

@ichernev How far along is this feature? This seems like it could be tied into extensibility with #1241

[glittle]

What is the status of pluggable calendar systems? Is it possible today? Is there documentation somewhere? Or does it still require plugins to implement?

[mattjohnsonpint]

Still requires plugins. A few are mentioned in the docs.

• Jalaali Calendar
• Hijri Calendar
• Taiwan Calendar