There will be a setting toggle to let user choose between 12/24 hour time format in v2.1. User story and settings spec: Bug 903683 For each app, the tasks to do after toggle is added would be: 1.Read/listen to the time format toggle value/change event. 2.Input the corresponding time format to existing mozL10n.DateTimeFormat() function. Currently the input time format should be a fixed 12 hour shortTimeFormat = %I:%M %p , line 201 of http://goo.gl/DR4CNe. There will be a 24 hour time format added. 3.Show the return of the function as it's doing now.
Test steps: 1. Open settings app 2. change the Time format settings in Settings > Date & Time > Time Format panel Expect: The time format in email app will be changed. here's the patch steps to apply correct time format: 1. include navigator.mozHour12 API shim in gaia app's html ``` <script defer src="shared/js/date_time_helper.js"></script> ``` (currently we still need at least `settings: readonly` permission in manifest, which might changed in next release) 2. detect proper time format via mozHour12 API, and get correct time format string from new 'shortTimeFormat12'/'shortTimeFormat24'. ``` var timeFormat = window.navigator.mozHour12 ? _('shortTimeFormat12') : _('shortTimeFormat24'); ``` 3. call mozL10n DateTimeFormat to localize it 4. listen to 'timeformatchange' event and localize time strings when its triggered The full usage is at (WIP) for reference.  https://github.com/mozilla-b2g/gaia/pull/22757/files
For the email app, we only use l10n_date's fromNow() method to show dates, so they are always relative to the user's current time, and not a fixed time display is used. So in that case, I do not believe we need to do these changes, but asking :gasolin for confirmation. On a side note, for me, it would be ideal if there was not a new 'timeformatchange' that was needed to listen for this but instead just have the normal localization change events occur and leverage those existing listener code paths. Maybe that is just an issue with this intermediate solution for 2.1, and if so feel free to ignore that feedback. But I am hopeful that we do not need to apply these changes at all given just the .fromNow use that email uses.
We filed per app bugs to make sure each functional team aware this change. `fromNow` shows strings like `an hour ago`... If email only use that I think it's fine for email app. Current API is a intermediate solution for 2.1. Post 2.1 API is still in discussion on bug 903683. I can remember there's a concern to patch l10n_date because they tend not to depend on settings and since currently API shim is in Gaia, we should not pollute gecko's `localization` event..
Since email is just using fromNow(), going to close this out as no work to be done/not applicable for the app.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.