Forum: General Topics

Today I recorded my first track. Start time of track is 10.18 UTC+1 (Italy) but when I look on the track information on website:

Added to site: 10-Sep-2011 09:18 UTC+1

It's not a big problem, maybe not a problem at all, but I don't understand the reason of this difference.


Btw, great program, I like it very much.

Hi Marco,

There is a small bug with Daylight Saving Time that I *thought* I'd fixed in the current version, but it turns out I didn't!! So the +1 is for your timezone, but your DST is neglected. I've fixed this for the next release, but for the moment (or until the clocks go back next month, assuming Italy is like the UK), you'll need to edit the timezone on the Track/Info page on the website to set it to +2.

The trackpoint difference is a bit odd, though it depends how long you had the track paused for (if at all). When uploading to the website there can be a discrepancy in that each phone 'transmission' can add a new point to the uploaded track, but I'm surprised if you've ended up with 300 extra trackpoint. What is your 'Transmit Interval' set at? Basically the smaller this is, the bigger the discrepancy might be...

Is the uploaded track otherwise the correct 'shape'?

Cheers,
Stephen

Hi Marco,

Sorry, I misread your first post!

I see what you mean now, this timing issue is odd - I've been trying to figure out what has happened. The first thing to note is that the Timezone listed on the Track/Info page should also include the DST (ie UTC+2 for Italy). Changing this will then make the 'Added to Site' time correct (I'm assuming you started the trip at around 10:18 local time), but will then shift the Start/Finish times 1 hour forward, so the question is why are these track times wrong.

Internally, both the website and TMJ-Mobile store all times as pure UTC+0, it is only when they are displayed on screen that the local timezone offset is applied. I've had a look at the raw track data on the webserver, including the logs of the data that your phone was uploading at the time. It turns out that the raw trackpoint times being uploaded were all 1 hour out, so for example at 8:18 (UTC+0) the phone was actually uploading data as 9:18 (UTC+0).

The most likely reason for this is that the timezone (or possibly DST setting) is set incorrectly in your phones Time/Date settings. This will probably affect the timestamp that the phones GPS provides to TMJ so needs to be correct for everything to work out. If the time settings are currently set to 'Get Time from Network' (or similar wording), try disabling this and set everything manually (I've found myself that sometimes the network time gives incorrect DST settings, which then puts everything else out). Once the timezone is correctly set, you might need to change the time itself, as it will probably have shifted an hour ahead.

Any luck?

Cheers,
Stephen

(ps: For your next trip try increasing the Transmit Interval, which should reduce the discrepancy between the number of uploaded trackpoints and the phone track.)

Could be the "Override GPS time"? I have it active because GPS time seems not using the DST, stucked on UTC+1 so 1 hour back of phone time.

Hi Marco,

It sounds like the phones DST setting isn't actually adding an extra hour to the internally stored time, or is at least not being handled correctly by the Java/J2ME components. When you made the change from UTC+1+DST to UTC+2 did you also have to alter the time itself so that the phones clock shows the right time?

Its also odd that the Override GPS Time option jumps the time by an hour, and possibly suggests that the GPS is giving TMJ a location timestamp in the local timezone, whereas this *should* be provided in UTC like everything else...

I've sent you a test version of TMJ off-list. In its About/Help screen it will show the raw time data that the phone provides to TMJ from its internal clock, as a Unix Timestamp (the number of seconds since 1/1/1970 Midnight GMT - this is how times are handled internally by all Java software). This should be equal to the value given on this site. It also shows the timezone and DST settings that the phone tells TMJ to use. If any of these are incorrect then it is almost certainly an issue in the phones time/date settings.

It might be that the only reliable way to get it to work is as you've found - ie by setting the phone to UTC+2 with no DST, although be aware that it might give strange consequences if you sync a PC calendar with your phone (eg appointments jumping forwards/backwards by an hour).

Good luck!

Cheers,
Stephen

Mmmm, there definitely seems to be a problem with the DST settings.

Your About screen *should* have read (at 21:58-ish local time in Italy):

Timezone: UTC 60 mins (120 inc DST)
Current UNIX Timestamp: 1315767477
Current UTC Time: 2011-09-11 195757

The UNIX Timestamp shows the root of the problem. This should always give the same value as on that other website, as should any phone, anywhere in the world. You say it is giving a higher number, I guess it'll be exactly 3600 higher (ie 1 hour measured in seconds)??

With the timezone set to UTC+2, no DST, and the phone clock set to your correct local time, do you then get the correct timestamp result?

Righto, hopefully everything else will work okay with these timezone settings as well.

Good luck!

Hi, Marco

  I just bought an XP3300 like you and install the TMJ. But my XP3300 cannot find the GPS signal. I saw that you worked well with the TMJ and XP3300. I want to know what is the TMJ version that you installed and are there any special setting of TMJ for XP3300?

I installed 2 version:

Generic MIDP2.0/CLDC1.1, Standard (JAR): can run but cannot find GPS signal, I just can find Bluetooth GPS in GPS setting.

Generic MIDP2.0/CLDC1.1, With JSR-179 Internal GPS (JAR):Cannot run after install. Display "unsupported MIDlet".

thank, Marco. Did you do any setting of XP3300 with GPS?

Macro, I want to know the firmware version of your XP 3300, would you please key in *#8375# and give me the output, thanks.

my output is :

[version]
LM3300_LEMU_V04

[VERSION] 9.1.0-28.0-1

This is what I get using the *#8375# command string. Hope it can help you.