Loading ...
Sorry, an error occurred while loading the content.
 

UTC Offset capability?

Expand Messages
  • Dave
    Hi, I m new to this group. I searched around recently looking for a way to display saved tracks from my travels in various parts of the world with the proper
    Message 1 of 6 , Aug 4, 2010
      Hi,

      I'm new to this group. I searched around recently looking for a way to display saved tracks from my travels in various parts of the world with the proper times, that is, the local time in the country (time zone) when the track was recorded. I'm a Garmin GPS Map60Cx user so the program I use to display my tracks, other than Google Earth, is Garmin's Mapsource. I can choose the way the time is displayed by changing the UTC offset in Mapsource's Preferences but then all other tracks I display will use that same "global" offset as well.

      Which leads to the reason I'm posting this in the GPX group: ignoring for the moment the issue of Daylight Saving, is there a way in the current implementation to include a UTC offset within a GPX file? If not, are there plans to include such capability in a newer version of the GPX format? That way tracks would always display with the actual time they were recorded.

      I understand that even if there was a way to include this information in the GPX file certain software programs like Mapsource would need to be changed to read and display the data properly, but that's beside the point of my question.

      Any information you can share would be appreciated,
      Thanks in advance,
      Dave
    • Alan
      The crude but effective method I use is to add/subtract 1 hour to/from your GPS track point time for each 15 degrees of longitude the point is ease/west of
      Message 2 of 6 , Aug 4, 2010
        The crude but effective method I use is to add/subtract 1 hour to/from your
        GPS track point time for each 15 degrees of longitude the point is
        ease/west of the Greenwich meridian.





        [Non-text portions of this message have been removed]
      • Jean-Claude REPETTO
        ... A better method should be to use a vectorial map of the time zones. Since the geographical coordinates are known, it will be easy to find the time zone.
        Message 3 of 6 , Aug 4, 2010
          On 08/04/10 23:29, Alan wrote:
          > The crude but effective method I use is to add/subtract 1 hour to/from your
          > GPS track point time for each 15 degrees of longitude the point is
          > ease/west of the Greenwich meridian.
          >

          A better method should be to use a vectorial map of the time zones.
          Since the geographical coordinates are known, it will be easy to find
          the time zone.

          Jean-Claude
        • Tim Thornton
          This is actually quite a complex issue if you want times used in country, as opposed to maritime time zones. For countries which have just one time zone, then
          Message 4 of 6 , Aug 5, 2010
            This is actually quite a complex issue if you want times used in country, as
            opposed to maritime time zones.

            For countries which have just one time zone, then the boundaries are pretty
            straightforward and don't change too often.

            But quite a few countries have multiple time zones, and if you go anywhere
            out of the way then the boundaries between one zone and another are
            generally not well defined.

            Also, countries change the time zone and the application of daylight saving
            time much more frequently than one may think - typically a change somewhere
            in the world every few weeks.

            If you want more info on this, a good starting point is
            http://www.twinsun.com/tz/tz-link.htm. The tz database is used in most Linux
            distributions, and is better than that in Windows.

            As far as including this information in GPS XML is concerned, you could do
            an extension like Garmin do depth and other data in their extension. It
            could either be a time offset, which gives the most flexibility, or it could
            be a parameter. If a parameter this would need to cover both the tz data and
            support fro maritime time zones. The offset is simplest to implement, but
            the parameter tells data users a bit about why the offset is what it is.

            Tim



            Smartcom Software Ltd

            Portsmouth Technopole

            Kingston Crescent

            Portsmouth PO2 8FA

            United Kingdom



            www.smartcomsoftware.com



            Smartcom Software is a limited company registered in England and Wales,
            registered number 05641521.



            From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf Of
            Jean-Claude REPETTO
            Sent: 05 August 2010 07:22
            To: gpsxml@yahoogroups.com
            Subject: Re: [gpsxml] UTC Offset capability?





            On 08/04/10 23:29, Alan wrote:
            > The crude but effective method I use is to add/subtract 1 hour to/from
            your
            > GPS track point time for each 15 degrees of longitude the point is
            > ease/west of the Greenwich meridian.
            >

            A better method should be to use a vectorial map of the time zones.
            Since the geographical coordinates are known, it will be easy to find
            the time zone.

            Jean-Claude





            [Non-text portions of this message have been removed]
          • Dave
            I can appreciate the complexity of the issue if one desired to make changes to the GPX file format. All I want to do is set an offset (in hours + or - UTM and
            Message 5 of 6 , Aug 5, 2010
              I can appreciate the complexity of the issue if one desired to make changes to the GPX file format. All I want to do is set an offset (in hours + or - UTM and ignoring Daylight Saving Time entirely) for a a particular saved GPX file so that the tracks I recorded in Fiji show the actual time the track was made, and a track I recorded in Paris shows the actual time, in Paris, when the track was made.

              I can do this on a file by file basis within Mapsource, as I mentioned, but that method is tedious. As is adding an offset to each and every trackpoint in the GPX XML code.

              But thanks for the feedback anyway. Perhaps there is no SIMPLE way to do what I want.


              --- In gpsxml@yahoogroups.com, "Tim Thornton" <tt@...> wrote:
              >
              > This is actually quite a complex issue if you want times used in country, as
              > opposed to maritime time zones.
              >
              > For countries which have just one time zone, then the boundaries are pretty
              > straightforward and don't change too often.
              >
              > But quite a few countries have multiple time zones, and if you go anywhere
              > out of the way then the boundaries between one zone and another are
              > generally not well defined.
              >
              > Also, countries change the time zone and the application of daylight saving
              > time much more frequently than one may think - typically a change somewhere
              > in the world every few weeks.
              >
              > If you want more info on this, a good starting point is
              > http://www.twinsun.com/tz/tz-link.htm. The tz database is used in most Linux
              > distributions, and is better than that in Windows.
              >
              > As far as including this information in GPS XML is concerned, you could do
              > an extension like Garmin do depth and other data in their extension. It
              > could either be a time offset, which gives the most flexibility, or it could
              > be a parameter. If a parameter this would need to cover both the tz data and
              > support fro maritime time zones. The offset is simplest to implement, but
              > the parameter tells data users a bit about why the offset is what it is.
              >
              > Tim
              >
              >
              >
              > Smartcom Software Ltd
              >
              > Portsmouth Technopole
              >
              > Kingston Crescent
              >
              > Portsmouth PO2 8FA
              >
              > United Kingdom
              >
              >
              >
              > www.smartcomsoftware.com
              >
              >
              >
              > Smartcom Software is a limited company registered in England and Wales,
              > registered number 05641521.
              >
              >
              >
              > From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf Of
              > Jean-Claude REPETTO
              > Sent: 05 August 2010 07:22
              > To: gpsxml@yahoogroups.com
              > Subject: Re: [gpsxml] UTC Offset capability?
              >
              >
              >
              >
              >
              > On 08/04/10 23:29, Alan wrote:
              > > The crude but effective method I use is to add/subtract 1 hour to/from
              > your
              > > GPS track point time for each 15 degrees of longitude the point is
              > > ease/west of the Greenwich meridian.
              > >
              >
              > A better method should be to use a vectorial map of the time zones.
              > Since the geographical coordinates are known, it will be easy to find
              > the time zone.
              >
              > Jean-Claude
              >
              >
              >
              >
              >
              > [Non-text portions of this message have been removed]
              >
            • Robert Lipe
              ... This is the group that focuses on the file format itself. That s why most of the answers clustered around that. We get to think about things like what
              Message 6 of 6 , Aug 5, 2010
                On Thu, Aug 5, 2010 at 3:37 PM, Dave <daveswarthout@...> wrote:

                > I can appreciate the complexity of the issue if one desired to make changes
                > to the GPX file format.


                This is the group that focuses on the file format itself. That's why most
                of the answers clustered around that. We get to think about things like
                "what if your track spans multiple time zones" and how to present that in
                the XML.



                > All I want to do is set an offset (in hours + or - UTM and ignoring
                > Daylight Saving Time entirely) for a a particular saved GPX file so that the
                > tracks I recorded in Fiji show the actual time the track was made, and a
                > track I recorded in Paris shows the actual time, in Paris, when the track
                > was made.
                >

                This really is up to the application displaying the time. The time inside
                a GPX file is always GMT.




                > I can do this on a file by file basis within Mapsource, as I mentioned, but
                > that method is tedious. As is adding an offset to each and every trackpoint
                > in the GPX XML code.
                >

                Doing that actually makes the file itself a lie, but I understand you just
                want it to "look right" in an application that doesn't allow what you're
                looking for.


                > But thanks for the feedback anyway. Perhaps there is no SIMPLE way to do
                > what I want.


                You can use the 'move' option of GPSBabel's track filter to do it in
                semi-automated way. It's still up to you to decide how many hours/minutes
                you want to shift the track.

                http://www.gpsbabel.org/htmldoc-1.4.0/filter_track.html


                RJL


                >
                > --- In gpsxml@yahoogroups.com, "Tim Thornton" <tt@...> wrote:
                > >
                > > This is actually quite a complex issue if you want times used in country,
                > as
                > > opposed to maritime time zones.
                > >
                > > For countries which have just one time zone, then the boundaries are
                > pretty
                > > straightforward and don't change too often.
                > >
                > > But quite a few countries have multiple time zones, and if you go
                > anywhere
                > > out of the way then the boundaries between one zone and another are
                > > generally not well defined.
                > >
                > > Also, countries change the time zone and the application of daylight
                > saving
                > > time much more frequently than one may think - typically a change
                > somewhere
                > > in the world every few weeks.
                > >
                > > If you want more info on this, a good starting point is
                > > http://www.twinsun.com/tz/tz-link.htm. The tz database is used in most
                > Linux
                > > distributions, and is better than that in Windows.
                > >
                > > As far as including this information in GPS XML is concerned, you could
                > do
                > > an extension like Garmin do depth and other data in their extension. It
                > > could either be a time offset, which gives the most flexibility, or it
                > could
                > > be a parameter. If a parameter this would need to cover both the tz data
                > and
                > > support fro maritime time zones. The offset is simplest to implement, but
                > > the parameter tells data users a bit about why the offset is what it is.
                > >
                > > Tim
                > >
                > >
                > >
                > > Smartcom Software Ltd
                > >
                > > Portsmouth Technopole
                > >
                > > Kingston Crescent
                > >
                > > Portsmouth PO2 8FA
                > >
                > > United Kingdom
                > >
                > >
                > >
                > > www.smartcomsoftware.com
                > >
                > >
                > >
                > > Smartcom Software is a limited company registered in England and Wales,
                > > registered number 05641521.
                > >
                > >
                > >
                > > From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf
                > Of
                > > Jean-Claude REPETTO
                > > Sent: 05 August 2010 07:22
                > > To: gpsxml@yahoogroups.com
                > > Subject: Re: [gpsxml] UTC Offset capability?
                > >
                > >
                > >
                > >
                > >
                > > On 08/04/10 23:29, Alan wrote:
                > > > The crude but effective method I use is to add/subtract 1 hour to/from
                > > your
                > > > GPS track point time for each 15 degrees of longitude the point is
                > > > ease/west of the Greenwich meridian.
                > > >
                > >
                > > A better method should be to use a vectorial map of the time zones.
                > > Since the geographical coordinates are known, it will be easy to find
                > > the time zone.
                > >
                > > Jean-Claude
                > >
                > >
                > >
                > >
                > >
                > > [Non-text portions of this message have been removed]
                > >
                >
                >
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
                >


                [Non-text portions of this message have been removed]
              Your message has been successfully submitted and would be delivered to recipients shortly.