Worldwide Basemap Software

[+fivegallon]

When playing back a "track" in the control centre,the time shows up as GMT,even though both my GPS and Laptop are on local time.

Looking through i can't find any preference or option settings to change this.Help file is no help.

 

Anyone got ideas on a fix?

[Neo_Geo]

Could you be more specific? What type of GPSr? What software? What laptop? What type of connection between the GPSr and laptop?

[+fivegallon]

Could you be more specific?  What type of GPSr?  What software?  What laptop?  What type of connection between the GPSr and laptop?

Magellan Map 330

Mapsend WorldWide BaseMap Software

Toshiba TE2100 1.6GHZ ,512MB Ram, 32MB GeForce 420Go ,20Gb HDD

Standard Magellan Coms link to serial port Item 730335

 

Specifics:After downloading a track from my GPS i open it up in the said software.The control centre allows you to play back the track.The field showing the time is never showing the correct time,it is 8hrs out. Given that the two countries i have done this in are both GMT+8hrs,it would appear that it is showing GMT.After much searching i am unable to come up with any means of changing this.Maybe you can help

Edited February 21, 2004 by fivegallon

[+Jamie Z]

Fivegallon,

 

I can't be of much help, but I've noticed this too. I'd like to know if there was a way to configure the tracklog to show a user-specified time-zone.

 

Jamie

[+fivegallon]

Fivegallon,

 

I can't be of much help, but I've noticed this too. I'd like to know if there was a way to configure the tracklog to show a user-specified time-zone.

 

Jamie

Jamie, what i have just found is a way to change the details(ie the time) AFTER you d/l the track.But ideally configuration setting is what we need.

 

To change AFTER: right click on the details on one of the track nodes and you are given an option to CHANGE Time and Date.

 

Edit:took out irrelevant comments and tidied up bracketed comment

Edited February 21, 2004 by fivegallon

[+fivegallon]

Anyone else using the Mapsend Worldwide BaseMap have ideas on this one?

[IceKnight (aka VectorJoe)]

The way fivegallon mentioned is the only way I have figure out how to do it.

 

However, once you modify one time point in a downloaded track, it modifies them all to fit relative to the one you changed.

 

So I suppose it's not too bad. It may be designed that way so that it works even if your were traveling in different timezones.....

 

But I think it would be an easy thing to write into the code to have the time zone set as a changable constant.

 

edited to add: my experience has been with Mapsend Streets and Dest US. but I figure it's the same for all the Mapsend products.

Edited February 24, 2004 by VectorJoe

[4x4van]

Yup, that's how Mapsend Topo works, as well. By changing the time on one of the trackpoints, the rest are updated accordingly. It would seem like it should use the time that the recording GPS is set to, but...

[+Prime Suspect]

When playing back a "track" in the control centre,the time shows up as GMT,even though both my GPS and Laptop are on local time.

Not really. It just appears to be on local time, because it's performing an offset calculation before displaying the time to you. Internally, it's UTC all the way.

 

Storing the track times in the local setting is pretty much a bad idea, especially if you have a unit that automatically adjusts the offset for DST. Think about it, and you'll see why.

[+fivegallon]

When playing back a "track" in the control centre,the time shows up as GMT,even though both my GPS and Laptop are on local time.

Not really. It just appears to be on local time, because it's performing an offset calculation before displaying the time to you. Internally, it's UTC all the way.

 

Storing the track times in the local setting is pretty much a bad idea, especially if you have a unit that automatically adjusts the offset for DST. Think about it, and you'll see why.

Ok,i understand what you mean with the first part and UTC.

But why is it a bad idea to store in local time(even given DST)?

Wouldn't it be better to be out by one hour rather than eight hours?(be a lot better to not be out at all obviously)

 

All that said Prime,what are the options apart from altering the file after the fact?

 

BTW:I appreciate the lesson

 

Edit:just another thought as i pushed the submit button.

Ok,it's performing an offset calculation,fine.But if it can report the local time on the display,why isn't it programmed to give the local time when downloading tracks etc? (that's not a question btw,just thinking out loud)

Edited February 24, 2004 by fivegallon

[4x4van]

Storing the track times in the local setting is pretty much a bad idea, especially if you have a unit that automatically adjusts the offset for DST. Think about it, and you'll see why.

Actually, I have thought about it, and it sounds like it would be a better idea to store track points with the Local time setting. After all, I traveled that route "at that locality and at that local time". What possible advantage would there be to saving it at UTC time?

 

Yes, I understand that if I'm now in another part of the world, those track times wouldn't be as relevant to my current location, but then I wouldn't be re-tracing that route if I were in another part of the world, now, would I? And if I did want to travel back to the "tracked" location to re-trace the route, then obviously the local time would be more relevant.

 

I can see that for military, Space Agency, or airline use, UTC recorded track points would be the way to go, but for consumers? I can see no possible advantage on the consumer's end for recording tracks in UTC, and if the unit's software can make the adjustment for the display (including DST, which mine does), then it could certainly make that adjustment for track points as well.

Edited February 25, 2004 by 4x4van

[+Prime Suspect]

Storing the track times in the local setting is pretty much a bad idea, especially if you have a unit that automatically adjusts the offset for DST. Think about it, and you'll see why.

Actually, I have thought about it, and it sounds like it would be a better idea to store track points with the Local time setting. After all, I traveled that route "at that locality and at that local time". What possible advantage would there be to saving it at UTC time?

 

Yes, I understand that if I'm now in another part of the world, those track times wouldn't be as relevant to my current location, but then I wouldn't be re-tracing that route if I were in another part of the world, now, would I? And if I did want to travel back to the "tracked" location to re-trace the route, then obviously the local time would be more relevant.

 

I can see that for military, Space Agency, or airline use, UTC recorded track points would be the way to go, but for consumers? I can see no possible advantage on the consumer's end for recording tracks in UTC, and if the unit's software can make the adjustment for the display (including DST, which mine does), then it could certainly make that adjustment for track points as well.

I didn't think I'd actually have to explain this.

 

What about when you're storing tracks and the time changes from DST to standard time? Suddenly, all the tracks you're making now have a timestamp that's 50 minutes BEFORE the tracks you made just 10 minutes ago.

 

What about if you're storing tracks while going across country? What do you do when you cross into another time zone? If you're heading west, your tracks are going to look like you've traveled back in time. Going east? Then you're going to have a strange 1 hour time gap in the tracks, where it will appear that you instantaneously stopped, waited for exactly 60 minutes, then began to move again, instantaneously accelerating to your previous rate of speed (in defiance of Newtonian laws of motion).

 

Using UTC is the only way to store the time info with the track in a logical, consistent manner.