Determine local time for future or past time | developer.brewmp.com Determine local time for future or past time | developer.brewmp.com

Developer

Determine local time for future or past time

Forums:

We have an email/calendar application. Each item (email, calendar entry) is associated with a timestamp in UTC. The issue here is how to display local time for each item.

BREW SDK provides API LOCALTIMEOFFSET, which returns the local timezone offset from UTC; If local timezone is in DST, it's already accounted for. The problem is that LOCALTIMEOFFSET returns the offset for the current time, but the local time offset for past or future time could be different because the past/future time might be in a different DST setting than _now_ (e.g. _now_ is in DST but the time we want to display isn't).

Thus using LOCALTIMEOFFSET we couldn't reliably display local time for any past or future time, and we couldn't find any API to get local time zone to compute local time ourselves.

Would you suggest a workaround for this problem? Granted, we could build a timezone table in our app and ask user to pick a timezone, but that's not an optimal solution because:
a. Every datetime dependent apps need to do the same.
b. It requires explicit user action when all should be transparent.
c. Casual users may not have the patience to discover and understand these settings.
d. Timezone is not automatically updated when user is traveling.

Note: Others have posted questions on this in not directly related threads, but I did not see any solution posted, thus promoting it to a separate thread.

I have filed SR119357011, and the response was:
It doesn't sound like a common problem that would be covered under the BREW API, however you may be able to write custom code to determine future/past times. I would suggest posting your question to the BREW developer community on the BREW Forums.

Thanks,
Jian

I donot think BREW API supported this req. till now. I agree that this is a good to have API.

I donot think BREW API supported this req. till now. I agree that this is a good to have API.

Jianliu,
For me it looks very simple. If you are going to give past/future time for the user on the same zone(otherwise user need to specify if he is travelling and want to get different zone's past/future time), then all you can find if the DST is enabled for that time period for that zone, as it will occur on specific period.
You also will be holding the list of zones that practices DST and the period in which DST enabled or not.
Check GETTIMEMS() also incase if it helps to get a work around.

Jianliu,
For me it looks very simple. If you are going to give past/future time for the user on the same zone(otherwise user need to specify if he is travelling and want to get different zone's past/future time), then all you can find if the DST is enabled for that time period for that zone, as it will occur on specific period.
You also will be holding the list of zones that practices DST and the period in which DST enabled or not.
Check GETTIMEMS() also incase if it helps to get a work around.

Hi Bru,
The problem with the approach you suggested (other than I need to have a table of timezone and DST start/off time), is that LOCALTIMEOFFSET gives you an offset, not a timezone. For example, GMT-5:00 could be Eastern (US, Canada) or Lima, or Bogota.
There is no way to tell whether I should adjust for DST, since different regions might have different policies regarding DST.
Thanks,
Jian

Hi Bru,
The problem with the approach you suggested (other than I need to have a table of timezone and DST start/off time), is that LOCALTIMEOFFSET gives you an offset, not a timezone. For example, GMT-5:00 could be Eastern (US, Canada) or Lima, or Bogota.
There is no way to tell whether I should adjust for DST, since different regions might have different policies regarding DST.
Thanks,
Jian

BREW's API related to timezone is not very well developed like windows CE/Mobile.
Similarly, you would also find that BREW has almost no support for code page based string conversion.

BREW's API related to timezone is not very well developed like windows CE/Mobile.
Similarly, you would also find that BREW has almost no support for code page based string conversion.