Best practices in retrieving a stable time in J2ME application (AT Commands)

[kurteknikk]

Hi,

I'm a J2ME developer which has a huge issue in retrieving a stable time in a J2ME application.

Of course the user can change the phone's time whenever he wants, so that's never an option to retrieve time.
The 2nd best practice is to sync the time difference with the server, but if there's no connection that also fails to work.

So does anyone have any better practice ? My idea was to use AT commands to get the gsm network time. But i'm not sure how that exactly work and what requirements does the phone need to be able to do it.

Anyone can provide some sample code or a good resource where to figure this out please ?

Regards,
Kurt

[hartti]

Why do you dismiss the phone time as a valid option? I would guess very few normal users change the time manually as it is possible to set the time to sync with network time (at least on many phones if not on all)...

What is your use case?

Hartti

[traud]

There is no AT command to receive the GSM network time. Even if there would be one, you are not allowed to connect to the local AT command interface from J2ME.

[kurteknikk]

Hi,

Sorry for a late reply but i wasn't notified about your replies anyway... My use case is that its an application for tracking company's security people so they can't afford that the user changes the time as if he was working at that particular time.

Any ideas ?

I've considered keeping an internal timer to detect the time difference but if for example getting the location takes a bit it might detect a 'change in time' while there wasn't.

[petrib]

Can't be done in a fully secure/reliable way.

Technically, hardware manufactuers could include a tamper-resistant/secure real-time clock in the device, which cannot be set/modified by software/apps, or by resetting, reformatting, reflashing the phone. However, as far as I know, no manufacturer has seen the need to invest in such technology.

So, make an app that keeps track of the time on your server, and clocks events at the server (which the users of your app has no access to). Then it doesn't matter what the phone time is, but what the time is at the server, which you can control. Then the tracking app must always have a network connection when it sends these tracking events (SMS would also do), but it never needs to care about what the phone's time/date settings happen to be.

[kurteknikk]

Can't be done in a fully secure/reliable way.

Technically, hardware manufactuers could include a tamper-resistant/secure real-time clock in the device, which cannot be set/modified by software/apps, or by resetting, reformatting, reflashing the phone. However, as far as I know, no manufacturer has seen the need to invest in such technology.

So, make an app that keeps track of the time on your server, and clocks events at the server (which the users of your app has no access to). Then it doesn't matter what the phone time is, but what the time is at the server, which you can control. Then the tracking app must always have a network connection when it sends these tracking events (SMS would also do), but it never needs to care about what the phone's time/date settings happen to be.

Thanks for your reply. The whole problem is when there's no "internet connection" because if network is just available i'm not going to send all tracking events via sms for normal fixes. That will be used for alarm situations because its too expensive for normal fixes especially in a country like Malta where sms messages are not that cheap.

I guess the best idea is just to keep a j2me timer in the app which just tracks the time i.e it ticks every second and i increase the time by one. Definately not the best environment to have more then 2 threads considering that we're speaking about a mobile phone but i guess there's no better alternative for this.

A bit disappointed no manufacture has seen the need to invest in such technology, i mean its just a 'simple clock' shouldn't be that bad i think...

[petrib]

So, the issue is NOT "huge", after all, and you CAN "afford to have the user changes the time as if he was working". Otherwise the data costs (packet data and/or SMS) would not be a problem for you. ;-)

Have you calculated how many "timer" events per user is generated, and how small of a data transfer would be required (or SMS), and how much that'd really cost per user per day? Is that cost really prohibitive?

[kurteknikk]

So, the issue is NOT "huge", after all, and you CAN "afford to have the user changes the time as if he was working".

I can "afford it" but the company doesn't because they have to pay the their employee for working hours for which he hasn't worked and i don't know if they will like that or not

Otherwise the data costs (packet data and/or SMS) would not be a problem for you. ;-)

True its not a problem for me, but as you might know in development any minimal problem / extra cost for your customer is usually the developer's problem not even the sales person's problem heh But of course i agree if there's a cost which one can't do without to provide a stable time the client either wants a stable time with costs or else have an "instable" time with less cost.

Have you calculated how many "timer" events per user is generated, and how small of a data transfer would be required (or SMS), and how much that'd really cost per user per day? Is that cost really prohibitive?

Haven't really calculated that one because it depends on the custom "time interval" request of the client but re-thinking about your idea got me inspired. Maybe i could send an sms to the server when there is no internet connection (for tags only of course) and then the events per user per day will be drastically minimized because its not that frequent like reporting fixes to a server.

Will require access to the phone's received messages, and some thinking about "setting" the time to keep it as reliable as possible (if a huge difference is detected in the timer thread compared to the phone's time) but i think there is a workaround for the client who really want to get a 99% "reliable time"