We're overusing the settings API for the |time.timezone| setting, which is a privileged API that cannot be exposed to web content. We should allow non-privileged apps and normal web content to receive the same notification whenever the time zone or DST is changed.

Are there use cases where an application wants to know about a timezone change but not any other kind of time change?

(In reply to Mounir Lamouri (:mounir) from comment #1) > Are there use cases where an application wants to know about a timezone > change but not any other kind of time change? System timezone change must imply a system clock change. The Gaia end must need to query the system clock again and update its UI things whenever the system timezone is adjusted. Currently, both the changes of system clock and system timezone will fire "moztimechange" events from Gecko to notify Gaia. The most weird thing to me is: we set our system clock through the Time API but set our system timezone through the Settings API. I think we should do them through the same mechanism; that is, the Time API. We should obsolete the over-usage by the Settings API.

Hi Mounir, Justin and David, Since we all agreed we should remove the |time.timezone| setting entry from the Settings API, the next question is, where should we do that setting? I think the best place is the nsIDOMMozTimeManager (.mozTime). Maybe we should add a new function like .setTimeZone(...) as below: interface nsIDOMMozTimeManager : nsISupports { /* * Set the system time. */ [implicit_jscontext] void set(in jsval time); /* * New */ [implicit_jscontext] void setTimeZone(...); }; In summary, we can 1. Use .mozTime.set(...) to set the system clock time. 2. Use .mozTime.setTimeZone(...) to set the system time zone. 3. Use |moztimechange| event to catch the time change (either by #1, #2 or system). 4. Do the following queries after getting the |moztimechange| event: a. Use |Date.now()| to get the current system clock time. b. Use |(new Date).getTimezoneOffset()| to get the current time zone. c. Use |(new Date).getDSTOffset()| to get the current DST info (Bug 861812). How do you guys feel?

(In reply to Gene Lian [:gene] from comment #3) > /* > * Set the system time. > */ > [implicit_jscontext] void set(in jsval time); > > /* > * New > */ > [implicit_jscontext] void setTimeZone(...); I'm curious what the arguments to these functions would be. > 1. Use .mozTime.set(...) to set the system clock time. > 2. Use .mozTime.setTimeZone(...) to set the system time zone. > 3. Use |moztimechange| event to catch the time change (either by #1, #2 or > system). > 4. Do the following queries after getting the |moztimechange| event: > a. Use |Date.now()| to get the current system clock time. The above seems reasonable to me, though I'm not at all an expert on B2G/Gaia issues. > b. Use |(new Date).getTimezoneOffset()| to get the current time zone. > c. Use |(new Date).getDSTOffset()| to get the current DST info (Bug > 861812). These APIs as the recommended APIs seem a little suspicious to me. What sort of operations would you do with these offsets? It seems better to use existing JavaScript APIs that can format dates appropriately rather than using these to build new ones.

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #4) > > [implicit_jscontext] void setTimeZone(...); > > I'm curious what the arguments to these functions would be. Yeap, this still needs discussion with Web API peers. > > b. Use |(new Date).getTimezoneOffset()| to get the current time zone. > > c. Use |(new Date).getDSTOffset()| to get the current DST info (Bug > > 861812). > > These APIs as the recommended APIs seem a little suspicious to me. What > sort of operations would you do with these offsets? It seems better to use > existing JavaScript APIs that can format dates appropriately rather than > using these to build new ones. The |(new Date).getTimezoneOffset()| is already an existing Date API. Right? And that's why I think maybe we should also add |.getDSTOffset()| in the Date object for symmetry. This is not yet a final decision. We need more opinions from different points of views.

(In reply to Gene Lian [:gene] from comment #2) > (In reply to Mounir Lamouri (:mounir) from comment #1) > > Are there use cases where an application wants to know about a timezone > > change but not any other kind of time change? > > System timezone change must imply a system clock change. The Gaia end must > need to query the system clock again and update its UI things whenever the > system timezone is adjusted. Currently, both the changes of system clock and > system timezone will fire "moztimechange" events from Gecko to notify Gaia. > > The most weird thing to me is: we set our system clock through the Time API > but set our system timezone through the Settings API. I think we should do > them through the same mechanism; that is, the Time API. We should obsolete > the over-usage by the Settings API. I'm not sure I understand what problems using a method compared to using a setting would solve.

Based on bug 861812, it seems that gerv has an opinion here. > I'm not sure I understand what problems using a method compared to using a setting would > solve. I think the argument in comment 3 is that this allows us to a) use the settings API for less stuff, since that's an inherently weakly-typed API b) use one JS object to set the system time and to set the system timezone. That seems pretty reasonable to me. > What sort of operations would you do with these offsets? It seems better to use existing > JavaScript APIs that can format dates appropriately rather than using these to build new > ones. Gaia really wants to know the UTC offset without DST applied, I think for their timezone picker. Anyway that doesn't seem to me like an unreasonable piece of data to expose, given that we already expose the UTC offset with DST applied?

My opinion is that he only right way to store information about a user's timezone is as an Olsen timezone database[0] identifier like "America/Los_Angeles" or "Europe/London". That allows any app with access to the Olsen database (which we should be shipping and updating as part of the platform, like other OSes do), given only UTC time (which the device should be using internally) to answer all of the time-related questions, such as: - What time is it for this user right now? - What time was it for this user at UTC time X? - Is the user in DST? - What is the user's DST offset? - When does the user change in and out of DST this year? and many others. Storing timezone offsets as "+0800" or similar only allows you to answer the first of those questions, and without other info would mean that the user would have to be regularly manually adjusting their clock. In addition, Olsen tz identifiers (combined with a map-based UI) are the best way to get timezone information from a user, and for the user to change the timezone of their device when they move from one location to another. So all APIs which get and set timezone information for the user should use Olsen identifiers as their parameters or return values, and we should provide a simple API to the tz database so apps can convert a UTC time and an identifier into answers to the questions listed above. To sum up: I don't care so much where we store the data, but I do care what data we store :-) Gerv [0] https://en.wikipedia.org/wiki/Tz_database , http://www.iana.org/time-zones

Ideally, yes, it's great to store a tz database identifier. However, there's not a whole lot of incentive for users to set those up correctly, especially on cell phones which get time and time zone information in NITZ messages over the cell network, but in which the zone is an offset from UTC. (Last I looked at the Firefox OS code for handling such messages, it would keep a user setting based on tz database identifier as long as the UTC offset and time combination in the NITZ message match the user's setting. But when there's a mismatch, we replace the setting with the raw UTC offset from the NITZ message.) Now there is publicly available (CC-0) data with map boundaries for the tz database regions at http://efele.net/maps/tz/ and I've even experimented with a JS library to map a latitude/longitude pair to an identifier at https://github.com/dbaron/tzmap.js , but I didn't get the latter down to a reasonable size or speed yet.

Can we store a TZ identifier if the user (or a JS library) sets one, and also store a NITZ offset which is used if there is no TZ ID? Remember some mobile networks (including mine in the UK) seem to send no (or bad) NITZ. Gerv

Closing as WONTFIX since FxOS is no more.