All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH 0/3] Patch Description
Date: Fri, 26 Nov 2010 14:44:08 -0600	[thread overview]
Message-ID: <4CF01C18.8070403@gmail.com> (raw)
In-Reply-To: <AANLkTikms4W-RTsmWuE9z1h1nRDC9-70+d9Y0j_nZ+Y2@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

Hi Andrew,

On 11/25/2010 05:25 PM, andrzej zaborowski wrote:
> Hi Yang,
> 
> On 25 November 2010 13:28, Yang Gu <yang.gu@intel.com> wrote:
>> This series of patch is to add provide local info support by requesting the terminal to send time and language info. Please comment on the following aspects as I'm not sure after reading the spec:
>> 1. Timezone may be a number in the range -47 through +48. In struct sms_scts, timezone is defined as gint8, thus 0xFF should shand for -1, which is a valid input. Thus I think build_dataobj_datetime_timezone() in src/stkutil.c is not correct. But I'm still not sure what value should be passed to oFono when timezone is absent.
> 
> I think you're right that build_dataobj_datetime_timezone() is wrong.
> Also note that sms_decode_scts() and sms_encode_scts() only allow the
> range -47 to 47, 48 would return an error.  I'm not sure what the
> unknown time zone should be represented as, here are some options:
> 
> * 0 (same as no offset)
> * 0xff because there's currently no GMT-00:15 time zone on earth
> (http://en.wikipedia.org/wiki/List_of_time_zones_by_country)
> * 0x80 (a currently unused value could be #defined as unknown time zone)
> * the struct could be extended with a .has_tz boolean.

The has_tz variable gets my vote.  The rest looks ugly, and I don't
really see +48 as a valid value.

> 
>> 2. DBUS_TYPE_BYTE represents an 8-bit unsigned integer, and D-Bus doesn't have a type related to 8-bit signed integer. So what's the best way to represent a timezone?
> 
> Maybe instead of asking D-bus, ofono should use tzset() to retrieve
> the time zone information and use localtime() for the other fields?

That is my preference as well.  Perhaps one can use the tm_gmtoff value
from struct tm to figure out the timezone.  See sms_scts_to_time for
more details.

Regards,
-Denis

      parent reply	other threads:[~2010-11-26 20:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 12:28 [PATCH 0/3] Patch Description Yang Gu
2010-11-25 12:29 ` [PATCH 1/3] network: Use bit as size instead of byte Yang Gu
2010-11-26 20:02   ` Denis Kenzior
2010-11-25 12:29 ` [PATCH 2/3] stk: Handle provide local info proactive command Yang Gu
2010-11-25 23:36   ` andrzej zaborowski
2010-11-26 20:49   ` Denis Kenzior
2010-11-29  2:47     ` Gu, Yang
2010-11-29 13:47       ` Denis Kenzior
2010-11-25 12:29 ` [PATCH 3/3] test-stk: Add provide local info Yang Gu
2010-11-25 23:25 ` [PATCH 0/3] Patch Description andrzej zaborowski
2010-11-26  3:29   ` Gu, Yang
2010-11-26 20:44   ` Denis Kenzior [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CF01C18.8070403@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.