Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-28278] Android: localized date/time format should default to numeric

GitHub Issuen/a
TypeBug
PriorityCritical
StatusClosed
ResolutionUnresolved
Affected Version/sRelease 9.1.0
Fix Version/sRelease 9.3.1
ComponentsAndroid
LabelsIntl, android, date, datetime, localization, parity
ReporterHans Knöchel
AssigneeJoshua Quick
Created2020-12-09T08:57:11.000+0000
Updated2020-12-18T19:31:31.000+0000

Description

Run the following code on your web-browser, iOS and Android: 
new Date(2020, 11, 9).toLocaleDateString('en');
The results are: * Web: 12/9/2020 * iOS: 12/9/2020 * Android: 12/9/{color:red}20{color} <-- YY instead of YYYY It seems like Android uses the wrong year format.

Comments

  1. Joshua Quick 2020-12-09

    This is not a bug. It's using the default pattern coming from the current locale. This just means the current locale is set up to use a 2 digit year. I've seen different locales provide 4 digit years on my devices as well. A great example of this is a Japanese "ja-JP" locale which does an ISO format of "yyyy/mm/dd" and requires a 4 digit year. Basically it's supposed to use the pattern the system is configured for. https://stackoverflow.com/questions/22719346/tolocaledatestring-is-not-returning-dd-mm-yyyy-format If you want a consistent format, then you will need to do this... 
       new Date(2020, 11, 9).toLocaleDateString(Ti.Locale.currentLocale, {
   	month: 'numeric',   // Will be 1-2 digits.
   	day: 'numeric',     // Will be 1-2 digits.
   	year: 'numeric',    // Will always be 4 digits.
   });
  2. Hans Knöchel 2020-12-09

    I don't understand. We do pass the locale to the toLocaleDateString function and all other platforms return the format correctly - on the same environment / locale.
  3. Joshua Quick 2020-12-09

    Currently, the toLocaleDateString() and toLocaleTimeString() methods use the "short" date/time patterns defined by the system. https://github.com/appcelerator/titanium_mobile/blob/master/common/Resources/ti.internal/extensions/js/Date.js But after having a look at Mozilla's docs [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString), the date/time components are supposed to be set to "numeric" if undefined. I can't find where this is documented in the ECMA spec (they say it's "implementation defined"), but I can see now this appears to be the expected behavior. Here's the quote from Mozilla's docs... bq. The default value for each date-time component property is undefined, but if the weekday, year, month, day properties are all undefined, then year, month, and day are assumed to be "numeric". So, you're right. We should change it to default to "numeric".
  4. Hans Knöchel 2020-12-09

    Thanks for the insight, Josh! Also, thanks for the workaround - we will patch the SDK and are ready to go then :-)
  5. Joshua Quick 2020-12-10

    PR (master): https://github.com/appcelerator/titanium_mobile/pull/12332
  6. Satyam Sekhri 2020-12-16

    FR Passed. Waiting for Jenkins build.
  7. Christopher Williams 2020-12-18

    merged to master, backport PR merged to 9_3_X for 9.3.1 target

JSON Source