ubuntu-phone team mailing list archive

[Tony Espy <espy@xxxxxxxxxxxxx>]

On 07/30/2013 05:44 AM, Iain Lane wrote:
> Hello,
> 
> In implementing the Time and Date settings[0], I need to know how to
> answer the question in the subject. We have NM's D-Bus API - does that
> cover all cases (mobile data, flight mode, containment [ok, that's not
> relevant for system settings, but more generally], ...) or is there
> something else to use here?
> 
> Cheers,
> 
> [0] https://wiki.ubuntu.com/TimeAndDate#Phone

Ian --

Looking at the TimeAndDate page, I'm curious why you need to know if
you're connected to the Internet?

It seems to me rather that if "Set the time and date" are set to
"Automatically", that you need an API to get at both time-zone and
current time/date from the 'net.

AFAIK, our only mechanism for getting time-zone automatically from the
'net is the NITZ messages that may be generated by mobile operators.
Unfortunately, these messages may not be fully qualified, as they're
provided by the operators, and AFAIK, TZ is either optional, or required
but not always sent.

Android apparently solves this problem by including a database of
operators that indicates whether or not their NITZ messages are fully
qualified.  If the operator is marked as sending incomplete NITZ
messages, then Android attempts to extrapolate the time-zone based other
information in the db.

There was a recent discussion about this with rsalveti, tvoss and a few
other folks.  We discussed whether it was appropriate for the platform
API to grab the NITZ value directly from ofono, and the consensus was
that it probably wasn't a good idea, and that instead we should explore
timed ( which is also being used by Jolla ), and have it be our
middleware master clock/TZ component that our platform API would rely
on.  There were some issues with timed including too much functionality
( eg. alarms ), however the core TZ/clock functions seemed like what we
needed.

That said, there hasn't yet been much action on getting timed into the
images and/or stripping some of the un-needed functionality.

So...  I guess the next question is does the platform API currently have
the functions you need ( eg. GetTimeZone(), GetCurrentTime() )?  If so,
perhaps we can implement a short-term solution for how these functions
are implemented until the timed solution is ready?

Regards,
/tony