CLJC java-time is awesome, as is the underlying library js-joda; however, locale and timezone support is a real hassle, not to mention that it can really bloat the code of the application.
All RAD needs is supplied by the built-in js Intl support (all browsers that matter support this now). The problem is that we want support for arbitrary date format strings, and that API doesn't directly support them.
This js library is almost exactly what I want: https://github.com/zapier/intl-dateformat, but the author of that one chose non-standard format characters, so making it isomorphic (as much as possible) with the JVM support is crappy.
Note that they tokenize the format string, then use their own library of data to resolve what each field means. I'm suggesting that the Intl's database (which is IN the browser already) could be used for this final step. For example, in js you can write:
var dtf = new Intl.DateTimeFormat("en", {timeZone: "America/Los_Angeles", month: "2-digit"});
dtf.format(new Date());
and get the 2-digit month for an English locale in Los Angeles' time zone.
hour12 true, false
weekday "narrow", "short", "long"
era "narrow", "short", "long"
year "2-digit", "numeric"
month "2-digit", "numeric", "narrow", "short", "long"
day "2-digit", "numeric"
hour "2-digit", "numeric"
minute | "2-digit", "numeric"
second "2-digit", "numeric"
timeZoneName "short", "long"
I realize that not ALL of the Java format specifiers are supported, but clearly the ones in the js API are sufficient for UI work.
So, the summary of the task is to make tformat in the date-time RAD namespace use a local hand-written formatter that leverages what's already in the browser instead of cljc.java-time's js-joda locale stuff.
awkay
commented
3 years ago
CLJC java-time is awesome, as is the underlying library js-joda; however, locale and timezone support is a real hassle, not to mention that it can really bloat the code of the application.
All RAD needs is supplied by the built-in js Intl support (all browsers that matter support this now). The problem is that we want support for arbitrary date format strings, and that API doesn't directly support them.
This js library is almost exactly what I want: https://github.com/zapier/intl-dateformat, but the author of that one chose non-standard format characters, so making it isomorphic (as much as possible) with the JVM support is crappy.
The solution is to use the definitions on this page: https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html
and write a string parser for format strings that can leverage the Intl API to create the proper elements of the string.
Similar to what Google Closure is doing (their library relies on packaging things the browser has as well, so it isn't a good solution). Their code is here: https://github.com/google/closure-library/blob/master/closure/goog/i18n/datetimeformat.js#L161
Note that they tokenize the format string, then use their own library of data to resolve what each field means. I'm suggesting that the Intl's database (which is IN the browser already) could be used for this final step. For example, in js you can write:
and get the 2-digit month for an English locale in Los Angeles' time zone.
The supported formats for Intl are here:
https://norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html (see table of option parameters, summarized below):
I realize that not ALL of the Java format specifiers are supported, but clearly the ones in the js API are sufficient for UI work.
So, the summary of the task is to make
tformatin thedate-timeRAD namespace use a local hand-written formatter that leverages what's already in the browser instead of cljc.java-time's js-joda locale stuff.