Last Comment Bug 714357 - API to enumerate available timezones and set timezone
: API to enumerate available timezones and set timezone
Status: NEW
: dev-doc-needed
Product: Core
Classification: Components
Component: DOM: Device Interfaces (show other bugs)
: Trunk
: ARM Gonk (Firefox OS)
: P1 normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 678695 714358 751011
Blocks: b2g-system-time 861795 714359
  Show dependency tree / graph
 
Reported: 2011-12-30 14:02 PST by Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
Modified: 2015-04-27 02:58 PDT (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
?
-

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-12-30 14:02:43 PST 
The initial implementation of this is only going to be used on gonk, and these three APIs are pretty closely related, so putting them in one work item.

Here's a strawman for the settings

  settings.time.useNetworkTime --- Boolean.  If true, use NITZ, NTP or other network-provided timezone/datetime info.  If true, the "timezone" and "datetime" settings below become read-only, but are updated as network time updates are received.

  settings.time.timezone --- String representing a timezone in one of the formats allowable for the TZ environment variable used by POSIX tzset().

  settings.time.msSinceEpoch --- Datetime as a number of milliseconds since the POSIX Epoch (i.e., 00:00:00 UTC on 1 January 1970).

It's less clear where enumerating preconfigured timezones should live.  This probably needs to be a privileged API since it adds fingerprinting bits.  But, a purely enumeration API isn't all that's needed to implement a settings application, because the timezone names would want to be localized.  So maybe it's just best to hard-code them for now.
Comment 1 Mounir Lamouri (:mounir) 2012-01-01 03:26:24 PST 
(In reply to Chris Jones [:cjones] [:warhammer] from comment #0)
>   settings.time.msSinceEpoch --- Datetime as a number of milliseconds since
> the POSIX Epoch (i.e., 00:00:00 UTC on 1 January 1970).

I don't really like having this as a setting because it will be a constantly moving value and I don't think we should have such kind of settings. I would prefer an API that allows setting the current time instead and getting it with a Date object. If we have such API, we could allow setting the timezone trough it.

> It's less clear where enumerating preconfigured timezones should live.  This
> probably needs to be a privileged API since it adds fingerprinting bits. 

If the preconfigured TZ live in Gecko, it will be the same for all Gecko users so fingerprinting wouldn't be an issue.
Comment 2 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-01-03 13:24:11 PST 
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #1)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #0)
> >   settings.time.msSinceEpoch --- Datetime as a number of milliseconds since
> > the POSIX Epoch (i.e., 00:00:00 UTC on 1 January 1970).
> 
> I don't really like having this as a setting because it will be a constantly
> moving value and I don't think we should have such kind of settings. I would
> prefer an API that allows setting the current time instead and getting it
> with a Date object. If we have such API, we could allow setting the timezone
> trough it.
> 

I don't understand how that's different.  It sounds like you're exchanging milliseconds for Date objects.

Date doesn't know about DST etc. AFAICT so I don't think that's a good interface for setting the timezone.  The timezone configuration is surprisingly complicated, see man 2 tzset.

> > It's less clear where enumerating preconfigured timezones should live.  This
> > probably needs to be a privileged API since it adds fingerprinting bits. 
> 
> If the preconfigured TZ live in Gecko, it will be the same for all Gecko
> users so fingerprinting wouldn't be an issue.

In Gonk they live in the low-level android system data.  That data might be different on different OS's.  But your argument may be sound.  However, I don't know of any use cases for enumerating available timezones other than to implement UI to set it, so keeping this privileged seems reasonable to start with.  My recommendation is to hard-code this in gaia anyway, for the sake of l10n.
Comment 3 Mounir Lamouri (:mounir) 2012-01-03 13:44:18 PST 
(In reply to Chris Jones [:cjones] [:warhammer] from comment #2)
> (In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #1)
> > (In reply to Chris Jones [:cjones] [:warhammer] from comment #0)
> > >   settings.time.msSinceEpoch --- Datetime as a number of milliseconds since
> > > the POSIX Epoch (i.e., 00:00:00 UTC on 1 January 1970).
> > 
> > I don't really like having this as a setting because it will be a constantly
> > moving value and I don't think we should have such kind of settings. I would
> > prefer an API that allows setting the current time instead and getting it
> > with a Date object. If we have such API, we could allow setting the timezone
> > trough it.
> > 
> 
> I don't understand how that's different.  It sounds like you're exchanging
> milliseconds for Date objects.

What I meant is that settings should be fixed values and "time.msSinceEpoch" is going to be a constantly moving value. I really don't think we should do that. Instead, we should have an API that allows setting the system time and getting the time could be done trough the Date object.

> Date doesn't know about DST etc. AFAICT so I don't think that's a good
> interface for setting the timezone.  The timezone configuration is
> surprisingly complicated, see man 2 tzset.

TZ could be a setting, sure. But if we have msSinceEpoch in an API we could also just use that API for TZ. I'm not sure what you meant by "that" in "I don't think that's a good interface".
Comment 4 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-01-03 14:27:31 PST 
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #3)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #2)
> > (In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #1)
> > > (In reply to Chris Jones [:cjones] [:warhammer] from comment #0)
> > > >   settings.time.msSinceEpoch --- Datetime as a number of milliseconds since
> > > > the POSIX Epoch (i.e., 00:00:00 UTC on 1 January 1970).
> > > 
> > > I don't really like having this as a setting because it will be a constantly
> > > moving value and I don't think we should have such kind of settings. I would
> > > prefer an API that allows setting the current time instead and getting it
> > > with a Date object. If we have such API, we could allow setting the timezone
> > > trough it.
> > > 
> > 
> > I don't understand how that's different.  It sounds like you're exchanging
> > milliseconds for Date objects.
> 
> What I meant is that settings should be fixed values and "time.msSinceEpoch"
> is going to be a constantly moving value. I really don't think we should do
> that. Instead, we should have an API that allows setting the system time and
> getting the time could be done trough the Date object.
> 

Date is unprivileged, but setting the datetime and timezone needs to be privilege.

I don't fully understand the objection to changing settings values.  Can you elaborate?

> > Date doesn't know about DST etc. AFAICT so I don't think that's a good
> > interface for setting the timezone.  The timezone configuration is
> > surprisingly complicated, see man 2 tzset.
> 
> TZ could be a setting, sure. But if we have msSinceEpoch in an API we could
> also just use that API for TZ. I'm not sure what you meant by "that" in "I
> don't think that's a good interface".

I thought you were proposing to change msSinceEpoch to an interface that set the timezone using a new Date object, which is what I was objecting to.  It seems natural to me to have these configuration values live in settings (although the system-clock setting will be implemented by the system HW clock, instead of the settings DB), so I'd like to understand your objection to that better.
Comment 5 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-01-03 14:28:16 PST 
(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> I don't fully understand the objection to changing settings values.  Can you
> elaborate?
> 

Sorry, "changing" here was ambiguous.  I meant it in the sense of "varying".
Comment 6 Mounir Lamouri (:mounir) 2012-01-03 15:18:22 PST 
Indeed, I wasn't proposing to use a new Date object to set those values but to get them (at least for the current time).

The reason why I don't want to have the current time in a setting is because the current time is not a setting. A setting is whether I'm using a NTP server to sync my clock and what is the server URL; it's my timezone; it's whether I have wifi disabled. Only static values. Values that could be stored in a database and an application would have to set them to change them.
With a dynamic setting we are breaking those implicit rules IMO. The value is no longer static and if it is, it will be set every ms which is insane. That means no change event will be fired but the setting will actually change.

IMO, the natural way to do that is to have an API that let changing the system time. We don't need anything for getting the time because |Date| is here for that. We could use that API to get the 'timechange' event.
Comment 7 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-01-03 16:25:15 PST 
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #6)
> The reason why I don't want to have the current time in a setting is because
> the current time is not a setting. A setting is whether I'm using a NTP
> server to sync my clock and what is the server URL; it's my timezone; it's
> whether I have wifi disabled. Only static values. Values that could be
> stored in a database and an application would have to set them to change
> them.
> With a dynamic setting we are breaking those implicit rules IMO. The value
> is no longer static and if it is, it will be set every ms which is insane.
> That means no change event will be fired but the setting will actually
> change.
> 

The concrete argument I see here is that with a varying system-clock setting, we wouldn't want to fire a "settings value" changed event on every clock tick.  OK, that's a good argument.

> IMO, the natural way to do that is to have an API that let changing the
> system time.

A new API for setting time is fine by me, just more overhead.  Let's bikeshed this away.  Strawman

  navigator.setSystemClockMs(ms)

> We don't need anything for getting the time because |Date| is
> here for that. We could use that API to get the 'timechange' event.

AFAIK, no one proposed adding new APIs specifically for getting the current time.  So I agree with you.
Comment 8 Mounir Lamouri (:mounir) 2012-01-04 06:18:49 PST 
(In reply to Chris Jones [:cjones] [:warhammer] from comment #7)
> > IMO, the natural way to do that is to have an API that let changing the
> > system time.
> 
> A new API for setting time is fine by me, just more overhead.  Let's
> bikeshed this away.  Strawman
> 
>   navigator.setSystemClockMs(ms)

I would prefer setSystemClock(Date) or maybe allowing |Date| or |ms|.
I'm not sure if having this is |navigator| makes a lot of sense but I don't see what we could do. Also, if we want a 'timechange' event, should it be fired on |window|, |navigator| or another object? I would tend to say |window|.
Comment 9 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-01-04 14:08:55 PST 
We need to be very careful about allowing Date, because the system-clock setting is number of milliseconds since Epoch in UTC.  We can define things so that that works though, if it seems helpful to others.  (I'm ambivalent.)
Comment 10 Mounir Lamouri (:mounir) 2012-01-05 02:16:45 PST 
(In reply to Chris Jones [:cjones] [:warhammer] from comment #9)
> We need to be very careful about allowing Date, because the system-clock
> setting is number of milliseconds since Epoch in UTC.  We can define things
> so that that works though, if it seems helpful to others.  (I'm ambivalent.)

I don't really like the idea of re-inveting the wheel because someone might mis-use a tool that already exist. We can get ms since epoch in the current TZ with Date with a simple computation so it doesn't sound a blocker to me.
Comment 11 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-01-09 10:43:46 PST 
A better API here would be adjustSystemClock(dtMs), where |dtMs| is the change in number of milliseconds.  That avoids clock skew from the UI choosing a date, and the platform actually setting it (which could be pretty much an arbitrary time in the future).
Comment 12 Mounir Lamouri (:mounir) 2012-01-09 14:06:54 PST 
(In reply to Chris Jones [:cjones] [:warhammer] from comment #11)
> That avoids clock skew from the UI
> choosing a date, and the platform actually setting it (which could be pretty
> much an arbitrary time in the future).

I didn't really understood that. Could you rephrase it?
Comment 13 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-01-09 14:19:54 PST 
A clock-setting application will do something like the following
 1. have UI for the user to choose the "current time"
 2. have a "Set" button, or something along those lines
 3. when the user clicks "Set", parse the time and convert it to a Date or milliseconds-since-Epoch value
 4. call navigator.set/adjustSystemClock()
 5. gecko calls clock_settime() (on POSIX)

The problem is, there's a theoretically arbitrarily long delay between (3) and (5).  Each millisecond that elapses between (3) and (5) is another millisecond the clock is off the value the user wanted.

Whereas with adjustSystemClock(), the client specifies an offset from the *current* time in (3).  That offset is still the same no matter how much time elapses between (3) and (5).  So step (5) would be, "call clock_gettime(), apply the offset, then call clock_settime()".

Does that make sense?
Comment 14 Mounir Lamouri (:mounir) 2012-01-10 05:34:06 PST 
Asking for the delta seems a pretty hard API.
Wouldn't that be easier if the Web facing API was requesting for a Date and we would convert this to a delta in the Gecko implementation so we would reduce as much as possible the difference when calling clock_settime(). The only delay would be between creating the Date object in the caller side and us doing the delta computation. Seems like we could make this insignificant, right?
Comment 15 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-07-26 16:29:27 PDT 
Arggghh, was looking over https://docs.google.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdENVekxYRjBTX0dCXzItMnRyUU1RQ0E#gid=0 and at the HAL implementation, and noticed we don't have this hooked up anywhere :(.

clee, is setting system time + timezone part of the v1 UI spec?  I sort of assume so, but not sure.  If so we need this API.

It looks like bug 714352 didn't actually hook up NITZ to the system-clock HAL, so we have no way at all to update the system clock.  The internal clock on phones is not reliable so this is actually a relatively bad problem.  The system time might drift up to the order of hours over a few months of use :/.

Another option is to implement a poor-man's SNTP with XHR and then use this API to update the time.  The problem with that approach is it hard-codes the timezone.

Either this bug or a followup to bug 714352 should block.  I don't have the powers to set flags ...
Comment 16 Jonas Sicking (:sicking) 2012-07-26 17:20:41 PDT 
I thought the idea was to set the timezone using the settings API. But we definitely need an API for setting the current time.
Comment 17 Mounir Lamouri (:mounir) 2012-07-27 12:33:35 PDT 
Bug 714358 is going to handle the time changes notifications and setting the time.
As Jonas, I thought setting the timezone would be done with the Settings API. I'm not sure what else should be needed for v1. Can't we just have available tz built in Gaia?
Comment 18 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-07-27 14:01:06 PDT 
Timezone via settings sounds great, but
 - we have to recognize when that changes and poke hal::SetTimezone
 - we have to connect NITZ up to that setting

(In reply to Mounir Lamouri (:mounir) (on VACATION until August 5th) from comment #17)
> Can't we just have available tz built in Gaia?

I don't know what you mean by this.
Comment 19 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-07-27 14:01:25 PDT 
Oh, I think you mean for enumerating.  Yes, that's not great but OK.
Comment 20 Andreas Gal :gal 2012-08-08 09:26:08 PDT 
Guys, do we still need this bug?
Comment 21 Andrew Overholt [:overholt] 2012-08-13 13:40:44 PDT 
(In reply to Chris Jones [:cjones] [:warhammer] from comment #18)
> Timezone via settings sounds great, but
>  - we have to recognize when that changes and poke hal::SetTimezone
>  - we have to connect NITZ up to that setting

Are these bug 714359 (or bug 714358) and bug 714352?
Comment 22 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-08-13 13:52:06 PDT 
No, those are different things.
Comment 23 Jonas Sicking (:sicking) 2012-08-15 10:40:11 PDT 
Minusing this since we don't need an API for enumerating available timezones in v1. We're filing a separate bug on specifically making it possible to set the timezone.
Comment 24 Philipp von Weitershausen [:philikon] 2012-08-15 10:48:40 PDT 
(In reply to Jonas Sicking (:sicking) from comment #23)
> Minusing this since we don't need an API for enumerating available timezones
> in v1. We're filing a separate bug on specifically making it possible to set
> the timezone.

Filed bug 783021.
Comment 25 Borja Salguero [:borjasalguero] 2012-10-26 02:09:49 PDT 
In 'First Time Usage' App we need to enumerate the list of 'timezones' available, and info related as:
GMT +2 Cairo, Bucharest... Also this info should be in Settings, Do we need a common way of retrieving this info? Probably if is not in API, some 'json' with this info in shared?

On the other hand we should rename this bug due to 'setTimezone' was in other specific bug.
Comment 26 Mounir Lamouri (:mounir) 2012-10-26 02:20:36 PDT 
Borja, as said in comment 17 and in comment 23, we don't need this for v1. Gaia can have its hard coded available timezones for the moment.
Comment 27 Borja Salguero [:borjasalguero] 2012-10-26 02:24:28 PDT 
For sure, we could create a 'timezones.json' in '/shared' for having the same set in Settings and FTU, what do you think?
Comment 28 Mounir Lamouri (:mounir) 2012-10-26 02:39:45 PDT 
I don't know how Gaia is working so I can't really give any opinion. You should probably open a bug for Gaia and ask Gaia peers their opinions.
Comment 29 Tim Guan-tin Chien [:timdream] (please needinfo) 2012-10-26 06:25:44 PDT 
(In reply to Mounir Lamouri (:mounir) from comment #28)
> I don't know how Gaia is working so I can't really give any opinion. You
> should probably open a bug for Gaia and ask Gaia peers their opinions.

The timezone json is currently stored in Settings app and <select> is created live according to it.

I will against moving this to b+; there are already Gaia feature done without this.
Comment 30 Andrew Overholt [:overholt] 2012-10-26 10:41:34 PDT 
Not blocking because we have a Gaia workaround.
Comment 31 Philipp Kewisch [:Fallen] 2015-04-27 02:58:10 PDT 
When you enable the API in bug 866301, you can possibly retrieve the timezones by fixing bug 837961 and/or bug 895737.
Note You need to log in before you can comment on or make changes to this bug.