Bug in duration shown for my tracks

[RsH]

I just downloaded 1.27.10 to check the latest pre-release, and loaded a small file to verify the problem.

Duration shows as 18:00:00 before I load the file. When I load the file that switches to 19:32:21 BUT the actual start time is 10:37:20PM and the actual finish time is 12:09:41AM the next morning, or 01:32:21 later. If the 18:00:00 is removed the elasped time is correct, but where that 18:00:00 comes from I know not, and THAT is the bug. All yours, Christian.

I also switched my machine's time display from AM/PM to 24 hour clock via the hh to HH change, using Windows settings, and it makes no difference within Route Converter, where it still shows the AM and PM <grin> so it is not machine setting dependent... That is just for the record...[attachment=205]

Incidentally I tried to add the postal address information just now and nothing connected or downloaded. However I had no problem with the location [Springville] or the Elevation. Those both downloaded. Is there something broken re downloading the postal addresses?

[routeconverter]

I just downloaded 1.27.10 to check the latest pre-release, and loaded a small file to verify the problem.

Duration shows as 18:00:00 before I load the file. When I load the file that switches to 19:32:21

Here it's 01:32:21. You obviously have an 18 hour offset. `Just a guess: Do you live in a timezone that's GMT-6?

BUT the actual start time is 10:37:20PM and the actual finish time is 12:09:41AM the next morning, or 01:32:21 later. If the 18:00:00 is removed the elasped time is correct, but where that 18:00:00 comes from I know not, and THAT is the bug. All yours, Christian.

Well, if I knew what's different on your machine...

I also switched my machine's time display from AM/PM to 24 hour clock via the hh to HH change, using Windows settings, and it makes no difference within Route Converter, where it still shows the AM and PM <grin> so it is not machine setting dependent... That is just for the record...

According to the Java docs, it's depending on the locale settings. You can control that with the language chooser in the misc tab.

Incidentally I tried to add the postal address information just now and nothing connected or downloaded. However I had no problem with the location [Springville] or the Elevation. Those both downloaded. Is there something broken re downloading the postal addresses?

Maybe Google did some maintenance?

[routeconverter]

I just downloaded 1.27.10 to check the latest pre-release, and loaded a small file to verify the problem.

Duration shows as 18:00:00 before I load the file. When I load the file that switches to 19:32:21

Here it's 01:32:21. You obviously have an 18 hour offset. `Just a guess: Do you live in a timezone that's GMT-6?

I've created a new prerelease to check that out. It prints time information if started from the commandline like this:

Code:

java -jar RouteConverter.jar

On my machine, the last lines are this for your file 2009 06 22 1837S.gpx:

Code:

GMT: Jul 11, 2009 2:12:19 PM
milliSeconds: 5541000 cal: Jan 1, 1970 2:32:21 AM
minus one hour: Jan 1, 1970 1:32:21 AM

What's the output on your machine?

[RsH]

To answer the main questions you ask, Christian

1. No, I live in Toronto, which is GMT-5 at standard time and GMT-4 during daylight savings time.

2. I am using Windows XP with SP3, the latest update to Java, and US English for the language and the keyboard.

3. Regional Options: Location is Canada... Standards and formats is English (United States)
Under Advance, Language for non-Unicode is also English (United States)

[routeconverter]

To answer the main questions you ask, Christian
1. No, I live in Toronto, which is GMT-5 at standard time and GMT-4 during daylight savings time.

Ok, then my theory for the 18 hours is wrong. Please send me the output of the prerelease version as described above. I hoped this helps tracking down the problem.

[RsH]

The window that opened showed the current time but also showed that at 0 milliseconds the time was December 31, 1969 at 7:00:00 PM and that less one hour it was December 321, 1969 at 6:00:00 PM, which is the 18 hours, in my view. So I then rebooted my ASUS motherboard computer and went into the BIOS and checked the motherboard's time. It was showing the CURRENT date and time, so the motherboard is not the source of this problem. I had done brief research which suggested a dead battery on the motherboard would cause this time to show, but since the motherboard and computer are relatively new, I am not taking the machine apart to check the battery, particularly when the bios reports that the date and time are correct.

Any other ideas? I sent the log as per your request in my previous email, and if you did not get it, let me know and I will send it again.

RsH [aka Bob]

[routeconverter]

Unfortunately, I'm not letting the program print out the relevant information into the log but onto the console. So I need the console output. The problem has to to do something with time zones, which I thought I had eliminated by explicitly using GMT.

[RsH]

Unfortunately, I'm not letting the program print out the relevant information into the log but onto the console. So I need the console output. The problem has to to do something with time zones, which I thought I had eliminated by explicitly using GMT.

[Also sent in an email...]
Keyed in manually from the Command Prompt window:

java -jar routeconverterprerelease.jar
Logging to C:\...\RouteConverter.log
GMT: Jul 13, 2009 11:15:39 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM
GMT: Jul 13, 2009 11:15:39 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM
GMT: Jul 13, 2009 11:15:39 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM
GMT: Jul 13, 2009 11:15:43 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM
GMT: Jul 13, 2009 11:15:43 AM
milliSeconds: 5541000 cal: Dec 31, 1969 8:32:21 PM
minus one hour: Dec 31, 1969 7:32:21 PM
GMT: Jul 13, 2009 11:15:44 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM
GMT: Jul 13, 2009 11:15:44 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM
GMT: Jul 13, 2009 11:15:44 AM
milliSeconds: 122000 cal: Dec 31, 1969 7:02:02 PM
minus one hour: Dec 31, 1969 6:02:02 PM
GMT: Jul 13, 2009 11:15:44 AM
milliSeconds: 3483000 cal: Dec 31, 1969 7:58:03 PM
minus one hour: Dec 31, 1969 6:58:03 PM
GMT: Jul 13, 2009 11:15:44 AM
milliSeconds: 5471000 cal: Dec 31, 1969 8:31:11 PM
minus one hour: Dec 31, 1969 7:31:11 PM
GMT: Jul 13, 2009 11:15:44 AM
milliSeconds: 5541000 cal: Dec 31, 1969 8:32:21 PM
minus one hour: Dec 31, 1969 7:32:21 PM
GMT: Jul 13, 2009 11:15:46 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM
GMT: Jul 13, 2009 11:15:46 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM
GMT: Jul 13, 2009 11:15:46 AM
milliSeconds: 122000 cal: Dec 31, 1969 7:02:02 PM
minus one hour: Dec 31, 1969 6:02:02 PM
GMT: Jul 13, 2009 11:15:46 AM
milliSeconds: 3483000 cal: Dec 31, 1969 7:58:03 PM
minus one hour: Dec 31, 1969 6:58:03 PM
GMT: Jul 13, 2009 11:15:46 AM
milliSeconds: 5471000 cal: Dec 31, 1969 8:31:11 PM
minus one hour: Dec 31, 1969 7:31:11 PM
GMT: Jul 13, 2009 11:15:46 AM
milliSeconds: 5541000 cal: Dec 31, 1969 8:32:21 PM
minus one hour: Dec 31, 1969 7:32:21 PM

C:\....\GPS [ended program, back to DOS prompt.

So the program seems to have done the same thing, time wise, three times in the above list of what appears in the Command Prompt window, before I closed the program down. However that GMT: Jul 13 2009 11:15:46 AM is NOT GMT, but the time here in EDT or GMT-4 in Toronto at this time, as it is the time showing on my computer. If it was supposed to be GMT then it would have to have been 3:15:46 PM or, without the AM/PM 15:15:46 GMT to match the local time. Note also that Windows XP is set to show a 24 hour clock on my desktop, so it shows 15:15 when it is 3:15 PM local time. That likely has nothing to do with the problem, as that is a recent change I made to my time display and the 18 hour difference existed before that change was made as well as now, after it was made. Also that 7PM time was there at 9AM this morning, local time, when I first ran the program and saw this type of display in the window, so that fact that the actual time changed by over 2 hours did NOT impact the result. All of the other times, and the millisecond offsets from 0 to the final value are identical. I do not recall if the intermediate millisecond numbers were the same or not, but that should not matter...

Hope that helps..

RsH [AKA Bob]

[routeconverter]

GMT: Jul 13, 2009 11:15:39 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM

That's the main line for me: it seems the locale has an effect on the time, i.e. 0 milliseconds is not Jan 1, 1970 00:00:00 in every Locale. I've read the Java code for a while now but still don't get the reason for this.

Anyway, please try the latest prelease 1.28.1 and send the output to this thread.

[RsH]

GMT: Jul 13, 2009 11:15:39 AM
milliSeconds: 0 cal: Dec 31, 1969 7:00:00 PM
minus one hour: Dec 31, 1969 6:00:00 PM

That's the main line for me: it seems the locale has an effect on the time, i.e. 0 milliseconds is not Jan 1, 1970 00:00:00 in every Locale. I've read the Java code for a while now but still don't get the reason for this.

Anyway, please try the latest prelease 1.28.1 and send the output to this thread.

Just downloaded the latest prerelease in both exe and jar versions and both show 1.27.16 as the version... and the time is still at 18:00 with the command prompt window showing the same values as before. Let me know when 1.28.1 is available.

It's now 1AM here in Toronto and I just did the downloads again and it is still showing 1.27.16 as the version I downloaded, both for the jar and the exe.

RsH [aka Bob]