ENVIRONMENT: ZTE Open revision 1.0.1.00.01.019.120 Build ID 20130531232151 BEHAVIOR: Currently, the only way of changing between 12hour and 24hour formats, is by changing the language. English changes the clock to a 12hour (am-pm) format. Portuguese and Spanish change the clock to a 24hour format. EXPECTED: There should be an option in the Clock menu within the Settings to change between those two formats. A user in the Mozilla-Hispano forums is asking about this: https://www.mozilla-hispano.org/foro/viewtopic.php?f=47&t=16353&sid=710678d125d4403de7749c3ac0a8c315 Please let me know if there is any additional information needed. Thanks in advance!! =)

I am looking at his bug and would like to fix it, but am not really sure how to do it. I was thinking of adding a checkbox to the settings app, but the difficult thing is in the properties files in gaia/shared/locales/date. I think it would need a property for the locale to define if 24-hour clock is default, and a prtoperty for the date formats in both 12 and 24 hours, since different locales can handle the starting 0 differently. Any opinions on how this should be done?

Evelyn can you give Casper some guidance on fixing this?

I think Kaze knows more on locale and time format. I will find sometime to take a look, keep my ni flag. ;)

It’s been discussed a few times already: the time format is currently bound to the locale, European locales have the 24-hour format, en-US has 12-hour. This allows to share a time format across all apps without requiring any settings permission (which is restricted to certified apps). However, things have changed a lot since 1.0, and now most apps already have settings permission (read access). Thinking out loud, we could do better by: • having two time formats per locale, e.g. shortTimeFormat12 and shortTimeFormat24 • define a default time format per locale: shortTimeFormat = {{ shortTimeFormat24 }} • define a setting to override the default time format (e.g. `time.format'). That way, all Gaia apps with settings permission (at least a read access) could use the preferred time format (as set by the user). Non-certified apps could still rely on the locale’s default time format if they reuse the date.*.properties resources, which (I think) is acceptable. If this sounds good to you, the FTU app could update the default `time.format' value, and the Settings app would allow to change it.

In the UK we use 24hr a lot, inline with the rest of Europe, however on Firefox OS we are forced to use en-US as there is no (yet) en-GB locale. On the back of comment #0 as user feedback and Kaze's suggestion above I'd like to mark this as papercut blocking.

(In reply to Beatriz Rodríguez [:brg] from bug 812419 comment #11) > I know we agreed a behaviour in the past which is very good but not covering > all the customers needs. > > This feature is requested by different sides, I would like to reopen it > based on comment 8 and 9. I will ni Mozilla Product team so they can add > this feature in the backlog (if it was not already there)and prioritize > accordingly. Pinging UX on this bug.

(In reply to Fabien Cazenave [:kaze] from comment #13) > > Pinging UX on this bug. Thanks Kaze.

Here is the UX spec.

Moving NI to Bruce

I previously had a duplicate in our backlog, so will track this one instead. The UX spec in comment 16 is a good start, but at the moment resourcing will be tough for 1.5.

I'm not sure where to comment between here and bug 1023735; choosing this one since it's generically in Gaia rather than in Gaia::Settings. Anywho, for the email app we are trying to avoid using the settings API at all and it appears from the email bug 1035759, the comments here, and the "User story" up top that the current plan is to use a setting and do stuff manually. Since bug 846200 will imminently allow for per-permission whitelisting this is not as bad as it could be, but I think it should still be avoided in favor of standards. And I think we've got standards that cover this. Specifically, we can do the following to find out if we should use 12-hour time or not: new Intl.DateTimeFormat([], { hour: "numeric" }).resolvedOptions().hour12 I would argue that the best thing we can do here is to: - Ensure that changing the setting affects the underlying Intl.DateTimeFormat implementation. Either by dynamically impacting live instances or future locale resolution mechanics. - Ensure that changing the settings UI triggers a 'languagechange' event (https://developer.mozilla.org/en-US/docs/Web/Events/languagechange). The rationale is that code like date_l10n that extracts information from the locale would do this. - Update https://github.com/mozilla-b2g/gaia/blob/master/shared/js/l10n_date.js to either: - listen for the 'languagechange' event so that it can self-update and reconfigure its relative time formatting string - Just be altered to rely on the underlying hour12 mechanics of Intl.DateTimeFormat. If the instances live-update, maybe there's no need to listen for 'languagechange', otherwise do.

(I commented in bug 1035762 before I saw this bug. Here's a copy&paste.) We specifically wanted to avoid the dependency on mozSettings for l10n.js and l10n_data.js. See bug 1013929 and https://groups.google.com/forum/#!msg/mozilla.dev.gaia/LSL5d3EOPAM/_Gtmc-B1DWgJ for examples. Does this bug mean that any app which wants to show dates and times to the user will require the 'settings' permission and thus will need to be certified? A few thoughts on the topic itself: I think it would be good to start to bring mozL10n.DateTimeFormat closer to the standard Intl.DateTimeFormat. Intl.DateTimeFormat takes an 'options' object as an optional second argument, which can have a boolean 'hour12' option set: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat#Parameters We could use this to control the behavior of localeFormat. I think this would require us to have translations for both 12-hour and 24-hour variants, in all locales. E.g. in English, instead of: shortTimeFormat = %I:%M %p we'd have: shortTimeFormat12 = %I:%M %p shortTimeFormat24 = %H:%M However, this doesn't work well with the current coding pattern which looks like the following and explicitly asks for the translation of "shortTimeFormat": var f = new navigator.mozL10n.DateTimeFormat(null, { hour12: false }); var format = _('shortTimeFormat'); element.textContent = f.localeFormat(d, format); Not to mention that we'd like to move away from inserting translations as textContent or innerHTML and use Mutation Observers and setAttribute('data-l10n-{id,args}') instead, as well as support an asynchronous version of mozL10n.get. We'll also need a way to react to the changes of the preference and retranslate and rerender the elements which have dates and times in them. Gandalf, any thoughts on this from your side?

From the user story: As a user, I want to customize the the time format _across the system_, such as 24 hour/12 hour clock. Acceptance: [...] 3rd party application behavior will depend on whether they are able to access the setting. WAT? How can this make sense? Also, I don't understand why we need this in addition to the locale (eg: US vs british)

(In reply to Julien Wajsberg [:julienw] from comment #21) > From the user story: > > As a user, I want to customize the the time format _across the system_, such > as 24 hour/12 hour clock. > > Acceptance: > [...] > 3rd party application behavior will depend on whether they are able to > access the setting. > > > WAT? How can this make sense? > Without an actual API that returns a system formatted time format, 3rd party apps will have to read the system setting and decide if they want to follow. Settings permissions are also in progress so this will actually be available to 3rd party apps eventually. At the moment we have no control over how 3rd party applications display their time formats. The acceptance is somewhat of a limitation of what we currently have. If there's a way to offer this feature to 3rd party applications without them having to read the setting then we can explore that as well. > Also, I don't understand why we need this in addition to the locale (eg: US > vs british) While in certain locales it may be more common to use one format vs the other, our method of locking the user to the format that we tied to a locale is really not flexible. It's a very common request from user feedback and from partners as well.

The original proposal came from comment 4 and the current use pattern of mozL10n.DateTimeFormat(). We can try to refine the proposal with the input started from comment 20, and 21. To me the time format setting is a user preference, hence it makes sense to have a setting field for it. So the problem become how does the setting change affect the UI of the gaia apps. If it is not desired for apps and l10n observing the setting change, maybe we can have system app set the preference to l10n and let it do the following UI changes.

Random thoughts: * locales should be able to default to one of the 12/24 options * we should allow the user to choose between 12/24 format overriding the default setting * this should be available to all apps, preferably as an API - mozL10n.DateTimeFormat seems to be a good fit * mozL10n.DateTimeFormat needs an API cleanup (move most to Intl.DateTimeFormat ?) * We should expose the @settings global to the localizer with hour12 boolean and have a single shortTimeFormat entity that resolves depending on that.

I wonder how much of it can be simply abstracted inside a locale variant instead of having a separate setting. I don't know if our current l10n framework can do this, but this looks more future proof than an invididual setting (think native i18n). From a technical point of view (certified vs other apps) it looks similar though (I somehow forgot that a locale change is currently handled with a setting).

(In reply to Julien Wajsberg [:julienw] from comment #25) > I wonder how much of it can be simply abstracted inside a locale variant > instead of having a separate setting. So you want us to create fictional locales like en-US-24h?

Yes that's what I have in mind. According to [1] BCP 47 accepts private subtags. But I'm no locale expert. Obviously we'd need a fallback facility (if we use locale XX-YY-ZZ and the requested key is not in this variant, then look in the locale XX-YY, and then in locale XX), but maybe it's already working like this ? [1] http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html

(In reply to Julien Wajsberg [:julienw] from comment #27) > Yes that's what I have in mind. According to [1] BCP 47 accepts private > subtags. But I'm no locale expert. I'm doing some investigation right now. The spec seems to suggest it is legal. Specifically http://www.ecma-international.org/ecma-402/1.0/#sec-6.2 says (With asterisks for my emphasis): === The ECMAScript Internationalization API identifies locales using language tags as defined by IETF BCP 47 (RFCs 5646 and 4647 or their successors), which may include extensions such as those registered through RFC 6067. Their canonical form is specified in RFC 5646 section 4.5 or its successor. BCP 47 language tags that meet those validity criteria of RFC 5646 section 2.2.9 that can be verified without reference to the IANA Language Subtag Registry are considered structurally valid. *All structurally valid language tags are valid for use with the APIs defined by this standard. However, the set of locales and thus language tags that an implementation supports with adequate localizations is implementation dependent.* The constructors Collator, NumberFormat, and DateTimeFormat map the language tags used in requests to locales supported by their respective implementations. === I'm gonna look a little more into the implementation to see what it would take for us to add/use a subtag.

(In reply to Julien Wajsberg [:julienw] from comment #25) > I wonder how much of it can be simply abstracted inside a locale variant > instead of having a separate setting. I don't know if our current l10n > framework can do this, but this looks more future proof than an invididual > setting (think native i18n). For me that that sounds like a dirty hack in place of a real solution. Doubling the number of locales, impacting the locale fallback chain (we'd need to recreate the fallback chain when user switches 12/24 setting) and altering navigator.languages and firing onlanguagechange when no language has been changed. To me individual setting sounds way more future proof.

It looks like there isn't really an existing subtag we could use for this and ICU's decision-making process doesn't seem set up for a minor adjustment to this, but we definitely can modify SpiderMonkey's locale resolution by just parsing out the subtag and using it to initialize the 'hour12' argument internally, taking care to let an explicitly user-provided option clobber it. === How ICU/JS does things: Consistent with TR35 section 2.6's (http://www.unicode.org/reports/tr35/tr35-dates.html#timeFormats) statement that "The preference of 12 hour versus 24 hour for the locale can be derived from the short timeFormat or from Time Data. If the hour symbol is "h" or "K" (of various lengths) then the format is 12 hour; otherwise it is 24 hour." the preferred hour is inferred from the short time field. http://dxr.mozilla.org/mozilla-central/source/intl/icu/source/i18n/dtptngen.cpp#566 is the code that infers fDefaultHourFormatChar and http://dxr.mozilla.org/mozilla-central/source/intl/icu/source/i18n/dtptngen.cpp#790 is where the 'j' format character that toBestICUPattern generates when it isn't explicitly overridden at http://dxr.mozilla.org/mozilla-central/source/js/src/builtin/Intl.js#2237 (And the resolvedOptions I reference in comment 19 translates that back out after ICU's resolved pattern is analyzed in resolveICUPattern at http://dxr.mozilla.org/mozilla-central/source/js/src/builtin/Intl.js#2641) === How we could do things The attached patch introduces support for locales like "en-US-x-moz24h" and "en-GB-x-moz12h" that change the behaviour as we desire. Assuming this does not seem insane or horrible to people, we could create a blocking bug in "Core :: JavaScript: Internationalization API" with a variant on this patch and also run this by more standardsy people.

Also, hour12 is just one of the settings that should be provided by the locale by default but allow the user to modify it. Others include: * Region * First day of the week * Calendar Gregorian/Hebrew/Persian etc. Each of them will operate in a similar way - impacting how we show time and dates. I'd say that trying to exploit BCP 47 is not scalable to that.

(In reply to Zibi Braniecki [:gandalf] from comment #31) > Also, hour12 is just one of the settings that should be provided by the > locale by default but allow the user to modify it. Others include: > * Region This is explicitly a documented tag in http://tools.ietf.org/html/rfc5646#section-2.2.4 and also mentioned in http://www.unicode.org/reports/tr35/#Field_Definitions > * First day of the week This does seem like it may not be covered by BCP47 stuff. But it also seems like this is a much less significant issue than the 12 hour/24 hour thing. Are there applications other than calendar apps that are likely to be affected by thins? It seems reasonable to have to override this on a per-app basis, whereas users seem likely to notice if a 12hour/24hour desire is not honored. The Unicode source doc on this seems to be http://www.unicode.org/reports/tr35/tr35-dates.html#Week_Data. This does seem to be covered by formatting strings, per http://unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table too. > * Calendar Gregorian/Hebrew/Persian etc. This is explicitly already supported by the Intl API via the "unicode locale extension sequences". SpiderMonkey's implementation explicitly supports calendar (ca) and numbering (nu). For example: -u-ca-gregory is a suffix. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat#Parameters for a brief overview and http://www.unicode.org/reports/tr35/#Key_And_Type_Definitions_ for more detail. > I'd say that trying to exploit BCP 47 is not scalable to that. Do you mean adding a whole bunch of -x-mozhack stuff? Because it seems like the whole point of the locale name encoding is to encode locale preferences based on iteratively applying overrides. It definitely seems more appropriate than requiring apps/webpages to do even more Mozilla-specific to work properly. The -x-moz12h/-moz-24h hack, for example, would transparently work on all webpages using the Intl API. It would be completely opaque to them, but that's arguably part of the intent. They would lose the preference if generating a different locale string themselves, but again, that seems desirable, since if they're picking a locale other than the user's default, then it's probably not appropriate to override the 12h/24h of the new locale.

One downside of using -x-moz12h is that it'd show up in all web requests, which increases the user finger print, and might cause all kinds of havoc in terms of web compat. This is fall-out from the UI being the web, once again. The web compat problem to me says that we shouldn't use locale codes to communicate this setting. If we had "private" and "public" versions, that'd be less of an issue, but that'd be a rather invasive patch, I guess? Otherwise I wouldn't be strictly opposed, the unicode guys have calendar stuff in there, see http://cldr.unicode.org/index/bcp47-extension for context and guidance. I'd like this to be a settings-free API that we can use in l10n.js or l10n_date.js easily. For the reason of finger-printing, I'm not sure if we should expose that API on the web in general. Probably good idea to get that to both API folks as well as privacy experts.

I should clarify that: - We would only need to specify -x-moz12h or -x-moz24h when the user is deviating from what the underlying locale already says. - If we would go ahead with -x-moz12h/-x-moz24h, we should make some effort to actually get the extension properly standardized and/or some other mechanism. - Assuming the user-agent outs that FxOS is in use, it's "only" an extra bit of entropy, and it's one that corresponds to actual user preference. I can't speak to how lost the fingerprinting fight is. - If we're assuming aggressively nefarious competent active fingerprinting, then even if we implemented the hour12 thing quasi-secretly, the fingerprinter could juse use the Intl APIs' resolvedOptions() to extract the entropy from the hour12 property on there. - I'm not really in love with this idea, but none of mozSettings/the ad-hoc settings in mozSettings/l10n_date are standards, whereas Intl is a standard, so I would generally characterize it as better than those.

(In reply to Andrew Sutherland [:asuth] from comment #34) > - I'm not really in love with this idea, but none of mozSettings/the ad-hoc > settings in mozSettings/l10n_date are standards, whereas Intl is a standard, > so I would generally characterize it as better than those. Yes, exactly. Going this way would allow to support all apps in a standard-compatible way. Using a mozSettings would not. I totally agree that it looks ugly. But the only good alternative I can see is, except of encoding all variants in a string, we could have a locale object with optional property. I don't know at all if that's planned in the Intl spec, but it could be a good feedback to report.

I'd lobby to limit our standards-exposure here. If we store the hour preference in the locale code, we have to standardize the locale code, and the js API to read it. Or we just do the js API, and store the user preference inside gecko. mozSettings would probably only be involved in setting that preference, but not in reading it, that'd be done by the mirrored gecko-side pref.

PS: the locale-dependent default should come from gaia in a way, as we don't localize gecko in fx os.

(In reply to Julien Wajsberg [:julienw] from comment #35) > Yes, exactly. Going this way would allow to support all apps in a > standard-compatible way. Using a mozSettings would not. What do you mean by "support all apps"? If we go with BCP extension, then l10n_date.js will have to extract it from navigator.languages. If we go with mozSettings setting, then l10n_date.js will have to use the setting. User facing API is the same in both cases, no? And we need SettingsAPI for apps anyway. It just seems to me that hour12 is one of many parameters that are system-wide, user-defined and should be accessible from apps.

It seems to me that mozSettings is only available for certified API, while the Intl API wil be available to content (but it's not available now, I agree). I won't comment more, you all know better than me here ;)

(In reply to Julien Wajsberg [:julienw] from comment #39) > It seems to me that mozSettings is only available for certified API, while > the Intl API wil be available to content (but it's not available now, I > agree). I thought that the plan is to change that so that you don't need to be a certified app to read user-defined settings? And if we don't want some class of apps (non-certified) to read user defined settings than I guess they should also not be able to read user-defined setting called hour12.

(In reply to Zibi Braniecki [:gandalf] from comment #38) > What do you mean by "support all apps"? If we go with BCP extension, then > l10n_date.js will have to extract it from navigator.languages. If we go with > mozSettings setting, then l10n_date.js will have to use the setting. User > facing API is the same in both cases, no? My proposal a la comment 19 is that anytime we want to know hour12 we would instead build on Intl standard. Specifically: var hour12 = Intl.DateTimeFormat([], { hour: "numeric" }).resolvedOptions().hour12; This works without having to parse the locale string at all. It works on Firefox, Firefox OS, Chrome, etc. Obviously the -x-moz12h and -x-moz24h overrides only work on a modified SpiderMonkey with the thing controlling the locale strings inserting them as appropriate. But l10n_date can go further and lose most of its own formatting code and just instead do: Intl.DateTimeFormat([], { hour: "numeric", minute: "numeric" }).format(Date.now()) Really the only thing l10n_date is doing that the standard does not support yet is the "10 minutes ago" part of the relative time stuff. Although the ICU database already has locale coverage for that if we look at: http://dxr.mozilla.org/mozilla-central/source/intl/icu/source/data/locales/en.txt#906 So I suppose a related question is whether l10n_date needs to let localizers second-guess the locale data that's already in ICU which is backing the Intl API stuff. Arguably if that is something we need, it should be done inside the Intl API rather than duplicating the strings and formatting logic, etc. > And we need SettingsAPI for apps anyway. It just seems to me that hour12 is > one of many parameters that are system-wide, user-defined and should be > accessible from apps. The email app has no longer has a dependency on the settings API at this time.

(In reply to Andrew Sutherland [:asuth] from comment #41) > The email app has no longer has a dependency on the settings API at this > time. If I understand this bug correctly, we're discussing how apps can depend on user defined setting. This setting will be set in Settings app and will be system wide. I lobby for using this as an example of a setting that should be accessible by apps. If we want to avoid exposing user-defined settings to apps and yet we want those apps to use those settings, I think we're making it hard on ourselves. One other idea would be to extend Intl to carry this information for us (Intl.Settings.hour12?), make it settable for Settings app only and readable for all apps. This doesn't mitigate fingerprinting[*] and dodges the elephant in the room in form of what I described above, but at least it does not impact locale fallback chain. [*] Is it even possible to avoid the fingerprinting here? User can just format the date and see the result and identify the relevant bit.

(In reply to Zibi Braniecki [:gandalf] from comment #42) > but at least it does not impact locale fallback chain. Can you clarify what you mean here? Is the concern that some code somewhere would see the locale string "en-US-x-moz24h" and would not be spec compliant and would then do something very buggy like decide that "en-US" is not what it should use and instead fallback to a hardcoded default like "fr-FR" (let's assume it's a French website.) > I lobby for using this as an example of a setting that should be accessible > by apps. It should absolutely be accessible to apps. But since we already have existing web standard APIs that relate to exposing the locale (like navigator.language) and interpreting locale stuff (Intl.DateTimeFormat/Intl.*), it seems odd to bias towards using the non-standard mozSettings API.

Building on the standard would make it possible to eventually expose this to the content. I doubt we'll ever expose mozSettings with standardized keys to the content.

I really think we need to remove the locale code from the thinking here. No webdev out there codes locale code parsing right, not even our webdevs do. Tucking things to the codes is like tucking things to the user agent. Yes, it shouldn't break things, but everything breaks. Let's not break the web, and leave the locale codes alone.

On the Intl API, should we really block on bug 866301, which depends on the Android one, bug 864843, which hasn't seen real traction since February? As much as I agree that that would be good, that sounds like an awful dependency at this point.

Gah! I don't know how I missed that we don't actually have Intl support on FxOS right now. Apologies for making misleading statements to the contrary. If you don't trust people do handle the -x-moz-12h locale stuff, that's reason enough for me given your experience with this, especially since the fallout from that could exceed the benefit. (:gandalf's experience trusted too, it just wasn't clear that that was his concern yet :) Regrettably the 24-hour preference does seem to be a prioritized 2.1 feature (per a private google doc); maybe we could use this to get the Intl API turned on? I hate seeing us still expending non-trivial effort adding to the stack of private hack-jobs when we could be using that effort to implement or improve standards. Or at least have our hack-jobs improve things for everyone instead of just the stock apps or apps that make themselves (more) Mozilla-specific.

Sadly, it's not a switch, but the problem right now seems to be that ICU doesn't compile for ARM architectures. Also, ICU comes with a lot of data and is going to increase image sizes a good deal, so I'm not sure how graceful it's going to be to switch on, once it's just a switch.

(Commenting a bit late since I was offline this morning.) It seems that there are two separate bugs involved here: 1. there is no standard API to get the user's preference wrt. 12/24 hour time format, 2. our non-standard API (mozSettings) is limited in that it requires the app to be certified and the permission associated with it grants access to all settings. For #1, I imagine that in the ideal world, there should be some UI in the Settings (in Firefox OS, or in Firefox) which allows the user to specify their preference. The UI should be separate from the one which sets the order of preferred languages. Whether the locale tag should or should not be the vehicle for storing this preference, I don't know yet. I think, however, that I lean towards what Axel said in comment 36 and comment 45, which is to leave the locale tag out of this. Even if the Intl API was available to us in Firefox OS, I'd be afraid of exposing preferences like this one via the locale code alone. I'd rather think there should be a navigator.mozHour12 bool property (name TBD), which we'll try to standardize. In the process, we could decide to also expose this on the locale code. If we start exposing -x-mox-12h to the Web right now, we're effectively teaching third-party devs about an implementation detail (where this pref is stored) that's only available on one platform. Also, Axel makes a good point: making locale tags more complex is risky as many website use very naive ways to parse them. In summary, I'd much rather prefer a non-standard navigator.mozHour12 property which can be properly detected by third-party code and, if present, used. Or, if the majority here agrees that we should not extend the navigator API with moz-prefixed properties, I think we should fix #2 which I mentioned above and make using mozSettings for this easy: don't require certification for reading settings and allow controlling permissions on a per-settings basis. (In reply to Andrew Sutherland [:asuth] from comment #41) > Really the only thing l10n_date is doing that the standard does not support > yet is the "10 minutes ago" part of the relative time stuff. Although the > ICU database already has locale coverage for that if we look at: > http://dxr.mozilla.org/mozilla-central/source/intl/icu/source/data/locales/ > en.txt#906 We actually do a few other things in addition to the standard. For instance, we recognize the %Eb token which stands for the month name in the genitive case for languages which need it ("of July" can be expressed as a single noun in a correct grammatical case in some languages): https://github.com/mozilla-b2g/gaia/blob/c329a67bafe60032820ab64b52c07c22eeff114e/shared/js/l10n_date.js#L50-L52 This is something strftime doesn't do, and something Intl.DateTimeFormat doesn't have in the spec either AFAIK. I'm thinking that we should also submit this to the standardization body for consideration.

(In reply to Staś Małolepszy :stas from comment #49) > 2. our non-standard API (mozSettings) is limited in that it requires the > app to be certified and the permission associated with it grants access to > all settings. This is going to be fixed in bug 846200. > In summary, I'd much rather prefer a non-standard navigator.mozHour12 > property which can be properly detected by third-party code and, if present, > used. Or, if the majority here agrees that we should not extend the > navigator API with moz-prefixed properties, I think we should fix #2 which I > mentioned above and make using mozSettings for this easy: don't require > certification for reading settings and allow controlling permissions on a > per-settings basis. In the case of time format we could use a boolean value that represents the preference so using navigator.mozHour12 looks good. However, in the next few release, we will allow users to set the preference on date format and I'm not sure if it is okay to expose the format string in navigator.mozDateFormat.

To summary of the thread, there are four major proposals (please correct me if there's any I've left) 1. create new `navigator.mozHour12` attribute to expose time format pref 2. expose mozSettings, app get's time format pref 3. expose mozSettings, app get's time format pref from shared/l10n_date 4. expand Intl to support mozHour12 time format pref For (4), Intl is not ready for our mobile platform(bug 866301), it looks risky to be delivered in 2.1. For (1), since expose settings (bug 846200) is planned, we may not need introduce new `navigator.mozHour12` for this case.

With bug 846200, will reading a permission still require the app to be certified?

(In reply to Fred Lin [:gasolin] from comment #51) > 4. expand Intl to support mozHour12 time format pref > > For (4), Intl is not ready for our mobile platform(bug 866301), it looks > risky to be delivered in 2.1. > For (1), since expose settings (bug 846200) is planned, we may not need > introduce new `navigator.mozHour12` for this case. I think I'm one of the big proponents of using Intl long-term. I should clarify that I don't think we'd need to add/expose a mozHour12 since you can already use resolvedOptions. I think my short-ish summary of my (long-term) proposal is: - Have the Intl APIs transparently use the user's preferred settings as part of the default locale configuration. Any changes to the user preferences should result in a "languagechange" event so that the web app knows it may need to re-instantiate its Intl.DateTimeFormat/etc. objects and regenerate its strings. I don't particularly care how this happens under the hood (synthetic locale/dynamic locale overlay/etc.) This should ideally be done by doing standards-talking with the standards people. I agree that the lack of Intl support in FxOS at this time (bug 866301) is a fundamental problem that won't be addressed in the 2.1 time-frame because of the disk space implications. I don't think that navigator.mozHour12 is worth pursuing unless we thought that was the long-term way this user preference should be exposed. So really using the preference is the only practical way. I do think we should update shared/l10n_date to transparently use the preference since then when we fix the problem in a standardsy way, that gets transparently fixed (although the settings permission is not so magic.) I want to make sure we move forward on the standards aspect of this; l10n people, I'm not sure if you have the mandate/time to spend on this, hopefully you do! But just in case, I'm needinfoing Ehsan since as WebAPI Tech Lead he might or know how to direct this to the JS team/etc./etc.

I've been thinking about this for a while, and I did research how Win32, OSX/iOS and Android solve this. Win32 and OSX expose this as part of their locale APIs. Win32's support here is way more elaborate than OSX, it basically lets you override the user settings when querying the information about the hour format, and if you choose to do so, you will get the locale dependent default hour format, and otherwise, the user's preferences take precedence. OSX uses a similar idea but as far as I can tell, it doesn't let you override user's settings. Android on the other hand provides an explicit API to query the user selected 12/24 hour time format setting, and they also take that setting into account when formatting a time string. I think that makes a good case for honoring the user's hour settings in the Intl.DateTimeFormat API if you request the system default locale, but we may need to expose the 12/24 hour format preferences separately as well. What I think we should _not_ do however is to extend the BCP47 code for the current locale with Mozilla specific tokens. Also, I don't think that we should use mozSettings API as a way to expose it (but it could be how we change the system wide setting on Firefox OS.) The other thing that we need here is an event which would be dispatched to pages when this setting changes. I think we may be able to use the existing languagechange event for this purpose, but I need to think about the implications of that more. I'll try to summarize my thoughts in the form of a proposal very soon, so I'm not clearing the ni? request yet. But in the mean time please let me know if this sounds sane or not. Thanks!

Sounds sane to me. My proposal of extending BCP47 was more a "quick and dirty" way using what we have now (like using mozSettings is), but if we add an API for this this sounds a lot cleaner.

Sounds we can start the work related to settings date&time panel around mozSettings. The way to monitor and expose 12/24 hour format preferencesto API need more detailed proposal and some gecko work.

Hi everyone, I was asked to comment here because not having a clear path forward on this feature will likely make this feature fall out of v2.1, in which we have strong partner demand to ship with this feature. I am not saying that this must be done what's comment 4 said, but doing anything that is not comment 4 was not part of v2.1 planning and we will have to rush to get that API implemented (in weeks). Ehsan, are you comfortable of such constraint? If not, we should really be looking at implementing a mozSettings shim for v2.1 and convert that to proper API in the future.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #58) > Ehsan, are you comfortable of such constraint? If not, we should really be > looking at implementing a mozSettings shim for v2.1 and convert that to > proper API in the future. That's also what I think we should do.

Hi Ehsan, we'd like to hear from you regarding to Comment 58, thank you. set ni flag in case this message is buried in bugmails.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #58) > Hi everyone, > > I was asked to comment here because not having a clear path forward on this > feature will likely make this feature fall out of v2.1, in which we have > strong partner demand to ship with this feature. I am not saying that this > must be done what's comment 4 said, but doing anything that is not comment 4 > was not part of v2.1 planning and we will have to rush to get that API > implemented (in weeks). > > Ehsan, are you comfortable of such constraint? If not, we should really be > looking at implementing a mozSettings shim for v2.1 and convert that to > proper API in the future. Do you mean you that you would like to use a mozSetting _even_ with an API proposed? That is not at all what my understanding from the 2.1 planning is. Andrew, Adam, do you know what we have agreed to for 2.1?

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #61) > Do you mean you that you would like to use a mozSetting _even_ with an API > proposed? That is not at all what my understanding from the 2.1 planning > is. Andrew, Adam, do you know what we have agreed to for 2.1? What I meant to say is that since there is unlikely we could have the proper API impl done in 1 week, having Gaia devs waiting for that will make this feature fall out of v2.1, which is 6 weeks away from FL. What I am proposing in comment 58 is that for 2.1 we should implement the API as a shim on top of mozSettings, so that Gaia work can be unblocked from Gecko (and we ship the shim, for v2.1). The shim is then removed when the proper API is in place. What's agreed on v2.1 planning was simply comment 4 -- there were no Gecko dependency and work planned. Does that sounds good?

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #62) > (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment > #61) > > Do you mean you that you would like to use a mozSetting _even_ with an API > > proposed? That is not at all what my understanding from the 2.1 planning > > is. Andrew, Adam, do you know what we have agreed to for 2.1? > > What I meant to say is that since there is unlikely we could have the proper > API impl done in 1 week, having Gaia devs waiting for that will make this > feature fall out of v2.1, which is 6 weeks away from FL. > > What I am proposing in comment 58 is that for 2.1 we should implement the > API as a shim on top of mozSettings, so that Gaia work can be unblocked from > Gecko (and we ship the shim, for v2.1). The shim is then removed when the > proper API is in place. > > What's agreed on v2.1 planning was simply comment 4 -- there were no Gecko > dependency and work planned. > > Does that sounds good? FWIW I think the implementation of the API on Firefox OS will be based on reading a setting value anyway, since that will be where we would store the preferred date format. Going ahead with mozSettings for this means that the API will be inaccessible to non-certified apps until bug 900551 lands (and I'm not sure if that will happen in time for 2.1), so the partner apps on Tako will be unable to use the API. If that is acceptable, then the above sounds fine.

Right, thanks. I think project management will reach out and find out if 3rd parties need access to the settings. In the mean time, since we are going to implement a API shim, it's probably better if you could share your thoughts on your proposed API.

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #61) > Do you mean you that you would like to use a mozSetting _even_ with an API > proposed? That is not at all what my understanding from the 2.1 planning > is. Andrew, Adam, do you know what we have agreed to for 2.1? I thought we committed to a proper API. Given timeframe and expectations here, it seems going with a mozSettings shim is prudent if that's acceptable technically.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #64) > Right, thanks. I think project management will reach out and find out if 3rd > parties need access to the settings. In the mean time, since we are going to > implement a API shim, it's probably better if you could share your thoughts > on your proposed API. I'm planning to send it to dev-webapi later today.

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #66) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from > comment #64) > > Right, thanks. I think project management will reach out and find out if 3rd > > parties need access to the settings. In the mean time, since we are going to > > implement a API shim, it's probably better if you could share your thoughts > > on your proposed API. > > I'm planning to send it to dev-webapi later today. https://groups.google.com/forum/#!topic/mozilla.dev.webapi/A2pt1kNSdag Please give feedback!

Update: On the requirement of 3rd-party access to the preference, Howie doubled confirmed with me it was not the original requirement. If it unfortunately have become a late requirement, we will have to rely on bug 900551. Wilfred is going to confirm with Tako project on this. Wilfred, please get back to us on this bug.

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #67) > https://groups.google.com/forum/#!topic/mozilla.dev.webapi/A2pt1kNSdag > > Please give feedback! This looks entirely doable to create an API shim :) I already have mozSettings wrapped in Promises in apps/keyboard/js/keyboard/settings.js :D

Fred, do you have concern on the approach and implementation? If not please file a dependent bug and start working the implementation. Thanks!

the settings work is planned in bug 1023735 already

(In reply to Andrew Overholt [:overholt] from comment #65) > (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment > #61) > > Do you mean you that you would like to use a mozSetting _even_ with an API > > proposed? That is not at all what my understanding from the 2.1 planning > > is. Andrew, Adam, do you know what we have agreed to for 2.1? > > I thought we committed to a proper API. Given timeframe and expectations > here, it seems going with a mozSettings shim is prudent if that's acceptable > technically. Agreed. At this point it's just making it work. If we need/want to revisit the implementation in a later release that's fine.

Even if bug 846200 lands in time for 2.1, won't it mean that apps that want to honor the user's time display preference will have to include a special permission in their manifest? That seems very ugly and a lot of noise for marketplace reviewers and users who are reviewing app permissions. Maybe bug 846200 could include a whitelist of settings that can be read by any app without permission? As a workaround (until we have some kind of proper navigator.timeFormat API) is there a way we can get the system app (or chrome code in b2g/chrome/content/) to listen to the time.format setting and communicate that value to all apps as a navigator property or a data- attribute on the HTML element, perhaps? I don't know what is possible there, but am hoping that there is some option that would not require all apps to request a permission if they want correct time display. Also, won't requing l10n.js to read a setting affect the startup time of all app?

(In reply to David Flanagan [:djf] from comment #73) > Maybe bug 846200 could include a whitelist of settings that can be read by any app > without permission? That would be awesome. We are going to have more functions similar to hour12, and I'm not sure if we will want to expose all of them on the navigator object (for example, in hour12=true, the "show am/pm" option exists in most OSes). Having a whitelist of settings that can be ready by any app without permissions would make it much cheaper for us to first add a new setting to Settings app, and see how apps use it before we standardize it as WebAPI.

(In reply to comment #74) > (In reply to David Flanagan [:djf] from comment #73) > > Maybe bug 846200 could include a whitelist of settings that can be read by any app > > without permission? > > That would be awesome. We are going to have more functions similar to hour12, > and I'm not sure if we will want to expose all of them on the navigator object > (for example, in hour12=true, the "show am/pm" option exists in most OSes). > Having a whitelist of settings that can be ready by any app without permissions > would make it much cheaper for us to first add a new setting to Settings app, > and see how apps use it before we standardize it as WebAPI. Is there any reason to not show am/pm in 12 hour mode?

User preference

(In reply to comment #76) > Created attachment 8464291 [details] > --> https://bugzilla.mozilla.org/attachment.cgi?id=8464291&action=edit > screenshot of 12/24 and am/pm in MacOS > > User preference Yes. My point was, does that make sense? :-)

ni jenny(UX) for feedback about extra User preference(AM/PM) from comment 74

(In reply to Zibi Braniecki [:gandalf] from comment #74) > (In reply to David Flanagan [:djf] from comment #73) > > Maybe bug 846200 could include a whitelist of settings that can be read by any app > > without permission? > > That would be awesome. We are going to have more functions similar to > hour12, and I'm not sure if we will want to expose all of them on the > navigator object (for example, in hour12=true, the "show am/pm" option > exists in most OSes). Having a whitelist of settings that can be ready by > any app without permissions would make it much cheaper for us to first add a > new setting to Settings app, and see how apps use it before we standardize > it as WebAPI. How about having a locale object under navigator? Then we can place all preferences on date/time, numeric, and currency formats in the object. And the values within the object could be linked to the settings db using similar mechanism of updating 'navigator.language'.

(In reply to Arthur Chen [:arthurcc] from comment #79) > How about having a locale object under navigator? Then we can place all > preferences on date/time, numeric, and currency formats in the object. And > the values within the object could be linked to the settings db using > similar mechanism of updating 'navigator.language'. That was my suggestion on webapi newsgroup - I'm not sure if the name should be 'language', but I believe we should have an intl prefs collection (hour12, am/pm, calendar, dec. separator etc.) (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #77) > Yes. My point was, does that make sense? :-) I believe so. I see a lot of cases since I moved to US where people don't use am/pm but they use hour12. So this option makes sense to me. Asking my friends around, some of them prefer am/pm, some without.

> Asking my friends around, some of them prefer am/pm, some without. They're using am/pm when necessary, I suppose? > won't it mean that apps that want to honor the user's time display preference will have to include a special permission in their manifest? I think we don't want to expose this to the other apps until we have a proper API. Otherwise this will lead to backward compatibility nightmare.

(In reply to Julien Wajsberg [:julienw] from comment #81) > > Asking my friends around, some of them prefer am/pm, some without. > > They're using am/pm when necessary, I suppose? So, I'd prefer to UX to make the call. My anecdotal interviews with my friends indicate that they often use time without am/pm unless it may be confusing (like movie at 7:00, carpool to work at 8:00). iOS lockscreen of my friend is 12h without am/pm. (so is most of "ios lockscreen" google image searches) > I think we don't want to expose this to the other apps until we have a > proper API. Otherwise this will lead to backward compatibility nightmare. Why not an API to pool system settings (whitelisted)?

I think we discussed enough already: * we have a proper way forward with a proper API for post-2.1 * we have a hacky solution for certified-only apps on 2.1 It's good enough for me. The only question I still have is: is there enough code to abstract to warrant a separate lib?

The code should be around 10 lines. Is it okay placing the code in l10n.js if we don't want a separate file?

(In reply to Fred Lin [:gasolin] from comment #78) > ni jenny(UX) for feedback about extra User preference(AM/PM) from comment 74 Hi Fred, I don't think it's necessary to further provide option for user to decide whether or not to show AM/PM, as the current UI is already filled with options. Tks!

As it seems there is still no conclusion on the API, the shim to be implemented on 2.1 may not be identical to the ideal form. That means once the *real* API is finished, apps will still have to do the migration. Which also makes the shim meaningless. However, given the limited time, we will start working on the shim as a workaround for 2.1 in bug 1023735 and apps have the choice of using the shim or not. The following will be implemented: - A script in shared/ implementing the shim. - The shim maintains a "navigator.mozHour12" property and fires a "timeformatchange" event to the window object when time format setting is changed. - A new time format string will be added to date.en-US.properties

Tako confirmation: The message from tako apps team is that we can live without access for 3rd party plus Date.toLocaleString in 2.1. The reason is that they believe it can be worked-around with mozSetting access. At the same time it is our firm belief this is a short-coming in the platform that should be addressed. So ideally we would like to see that Mozilla makes an effort to implement the desired behavior in the 2.2 time frame.

Is this expected to pick the configuration correctly from the locale out of the box? Because when I updated my phone to a Gaia that had 24 hour time support I got 24 hours even though I have an en-US device.

I expect it to, in particular in the software update case.

Add the test cases. https://moztrap.mozilla.org/manage/cases/?filter-suite=747

To update the dependent bug based on Comment 87

Assign to me for tracking purpose -- to be closed when all dependent bugs are fixed.

All dependencies resolved, thanks for everybody work on this user story \o/

This issue is verified fixed on Flame 2.1(319mb) Flame 2.1(319mb) Environmental Variables: Device: Flame Master (319mb) Build ID: 20140903000204 Gaia: fbb297c39aab5f17b179533d2a9a6c5166b2c197 Gecko: fb5e796da813 Version: 34.0a2 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Actual Result: The time is set by default depending on the local. The user is able to override and toggle 12/24 hour clock in Settings.

All areas that deal with correctly changing from 12hr>24hr time format or vise versa in Clock, Contacts, Cost Control, SMS, Dialer, Updating and taking time from Locale, and Calendar are working as expected by showing the time based on the format they are in on both 2.1 and Master. ________________________________________________________________________________________________________ I am unable to verify this bug until all bugs within this user story are verified The following bugs within this user story are not closed, and/or verified. - bug 973441 - bug 968686 - bug 975249 - bug 985112 - bug 846200 - bug 1058158 - bug 1055898 - bug 1053190 - bug 1035775 -bug 1053024 -bug 1063839

Derek - Why would bug 1063839 affect this user story? bug 1063839 is dealing with date format, where as this user story deals with time format.

The date format is included in the PDF that is attached to this bug. Everything in the user story of this bug seems implemented now though. Should I remove bug 1063839 and verify this bug?

(In reply to Derek Harris [:DerekH] from comment #97) > The date format is included in the PDF that is attached to this bug. > Everything in the user story of this bug seems implemented now though. > Should I remove bug 1063839 and verify this bug? Gerry - Can you confirm that this user story is only focused on 24 time format, not the date format? If that's the case, then I'll remove bug 1063839 and mark this bug verified.

Hi Jason, Yes, the user story only focused on 24 hour time format.

The company I work for has a need for 24 hour time format using the US Locale (or at least US date format). We use an application for network management. All of our other systems use 24 hour format (our business is transportation related) with US date format. Can anyone say if/when this capability will be supported in Firefox browser? Thanks

(In reply to Robert G. from comment #100) > Can anyone say if/when this capability will be supported in Firefox browser? This bug is related to Firefox OS (mobile operative system) and it's fixed in version 2.1, not even sure how the question relates to a browser. I suggest to use https://support.mozilla.org/ or IRC (https://wiki.mozilla.org/IRC) for further questions, especially given the amount of people receiving notifications from this bug.

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #55) > I think that makes a good case for honoring the user's hour settings in the > Intl.DateTimeFormat API if you request the system default locale, but we may > need to expose the 12/24 hour format preferences separately as well. What I > think we should _not_ do however is to extend the BCP47 code for the current > locale with Mozilla specific tokens. Also, I don't think that we should use > mozSettings API as a way to expose it (but it could be how we change the > system wide setting on Firefox OS.) How does the phone inform dynamic server-side webapps (where rendering of dates/times happens server-side based on Accept-Language) of the 12/24hour preference?

Nathan, this is a really good question, but I think it will be better answered on the mailing list dev-gaia or dev-b2g. (I don't have the answer -- but I fear we don't give the information)

Now that we have Intl switched on on fxos, we should use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat, and the hour12 there is locale dependent. Maybe we could even add user-choice in the middle of that.

Pike, this is not server-side :)

Filed bug 1187539 to get the automatic option for mozHour12 to let us use Intl's default setting for the given locale.