Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-28251] Android: Add missing options to Intl.DateTimeFormat.resolvedOptions()

GitHub Issuen/a
TypeImprovement
PriorityLow
StatusClosed
ResolutionUnresolved
Affected Version/sRelease 9.1.0
Fix Version/sRelease 9.3.1
ComponentsAndroid
LabelsDateTimeFormat, Intl, android, locale, parity, timezone
ReporterHans Knöchel
AssigneeJoshua Quick
Created2020-11-20T11:18:33.000+0000
Updated2021-01-08T14:57:06.000+0000

Description

Compared to iOS, the Android implementation seems to maintain a custom version of Intl, resulting in unexpected API gaps, e.g. for time zones (Intl.DateTimeFormat().resolvedOptions().timeZone). Can it maybe use the one V8 brings already?

Comments

  1. Joshua Quick 2020-11-20

    We document what is supported on Android and iOS here... https://docs.appcelerator.com/platform/latest/#!/api/Global.Intl The only gaps between Android and iOS that I'm aware of are: * Android doesn't support all Collator options like iOS. * The DateTimeFormat.resolvedOptions() is admittedly half-assed since there isn't a nice way to "fully" implement it using the standard Java framework. _(But it can be improved.)_ We can add additional features upon request. We don't have a problem with that. Adding "timezone" to resolvedOptions() is easy to do. {quote}Can it maybe use the one V8 brings already?{quote} That's not a good idea. This would involve including the ICU C++ library which is about 20 MB per architecture. This library is way too big and not mobile friendly. Especially since Google Play has an APK size limit of 100 MB. This is why we've written our own custom implementation... and our competitors do the same for the same reason. _(Google provides ICU Java classes as of Android 7.0, but we're several years away until we can make that our min OS version.)_ We have written extensive unit tests for the Intl API that is used to verify Android's behavior against iOS. This should give you confidence about all of the other APIs. https://github.com/appcelerator/titanium_mobile/blob/master/tests/Resources/intl.test.js https://github.com/appcelerator/titanium_mobile/blob/master/tests/Resources/intl.collator.test.js https://github.com/appcelerator/titanium_mobile/blob/master/tests/Resources/intl.datetimeformat.test.js https://github.com/appcelerator/titanium_mobile/blob/master/tests/Resources/intl.numberformat.test.js https://github.com/appcelerator/titanium_mobile/blob/master/tests/Resources/date.test.js https://github.com/appcelerator/titanium_mobile/blob/master/tests/Resources/number.test.js https://github.com/appcelerator/titanium_mobile/blob/master/tests/Resources/string.test.js *Side Note:* Apple's JavaScriptCore and Google's V8 don't have full parity when comes to Intl APIs anyways. So, platform specific code has to be implemented regardless.
  2. Hans Knöchel 2020-11-20

    Thanks Josh! For now, I unblocked us by adding DateTime.getDefault().id in our internal native "ti.polyfill" module. It does exactly the job Intl.DateTimeFormat().resolvedOptions().timeZone does.
  3. Joshua Quick 2020-11-21

    PR (master): https://github.com/appcelerator/titanium_mobile/pull/12282 _(Note that "master" is now Titanium 10.0.0.)_
  4. Samir Mohammed 2021-01-07

    FR Passed, waiting on Jenkins build
  5. Christopher Williams 2021-01-07

    merged to master, backport PR for 9_3_X is in progress.
  6. Christopher Williams 2021-01-08

    merged to 9_3_X for 9.3.1 target.

JSON Source