Supporting TimeZones is essential for mobile Business App TimeTracker.


TimeTracker ‘knows’ some different kinds of  TimeZones:

  • current TimeZone detected from current Location
  • @Home TimeZone aka Company TimeZone
  • UTC / GMT TimeZone with Offset +00:00

By default the local TimeZone is visible for the User.

@Home / Company TimeZone is stored under User Settings.

UTC is always used by internal calculations.

As long as the TimeZone is the current TimeZone it’s easy to get by C++, because the TimeZone is available from CalendarService:

// .hpp
bb::pim::calendar::CalendarService mCalendarService;

// .cpp
QString ConnectedCalendar::currentCalendarTimeZone()
    return mCalendarService.settings().currentSystemTimezone();

There’s a list of all available TimeZones available deep inside BlackBerry 10. From Device Settings – Date and Time Users can select a TimeZone:


Unfortunately this list isn’t available from Cascades – there’s no API 😦

So I had to rebuild this from informations in the web on the TimeZones used by BlackBerry.

If selecting a TimeZone manually at first you have to select a Country:



I have not implemented logic to find out if the selected TimeZone is using DST (Summertime) for a given Day, so the User will be asked:


This is only needed in very rare cases, so I think we can live with the workaround – hopefully Cascades will support this soon.

Here TimeZone ‘America/Los_Angeles’ DST was selected:


Please take a look at the calculated time: 18:36 from 13:37 to 23:13 – TimeTracker caclulated correct because there’s a TimeZone difference of 9 hours between +02:00 and -07:00.

Calendar && two TimeZones

TimeTracker entries can automatically be added to a connected Calendar.

TimeTracker supports multi TimeZones per item as you can see above where we started in Germany and stopped in LA.

Calendar only supports one TimeZone per event, so we have to recalculate start and stop times both using the TimeZone from start. Here’s the corresponding Calendar Event from tracked time with two TimeZones:


Instead of Event ending on July-14 23:13 the Calendar entry ends on July-15 08:13. To inform the user about the real stop time, I added a comment under ‘Notes’.

Here are the times details from Calendar Event:


As usual: all complexitiy hidden to the User !

More infos::