Year 2016 problem

Bug #1530670 reported by Daniel
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
igotu2gpx
Confirmed
Undecided
Unassigned

Bug Description

I just discovered that my i-gotU GT-120 doesn't properly work in the Year 2016:

I recorded two tracks, one on 2015-12-31, one on 2016-01-01. The igotugui reports them as 2015-12-31 (correct) and 2000-01-01 (wrong year).
Another check today revealed that month, day and time are correct, only the year 2016 is set to 2000. I'm not sure if this is a device or software problem, but a test with the original software @trip PC (old version because I didn't update Windows for years) doesn't even show these two tracks from the year 2016.

Also in the exported GPX file, the year is 2000, see attached files.

No matter where the problem is, I think it's easy to implement at least a hack which fixes years <2010 or so by adding 16 to them.

me:~$ dpkg -s igotu2gpx
Package: igotu2gpx
Architecture: amd64
Version: 0.4.0-0~227~10~saucy1

me:~$ uname -a
Linux 3.13.0-74-generic #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

me:~$ lsb_release -a
Description: Ubuntu 14.04.3 LTS

Related branches

Revision history for this message
Daniel (hackie) wrote :
Revision history for this message
Daniel (hackie) wrote :
description: updated
Revision history for this message
Ronald Van Iwaarden (ron-vaniwaarden) wrote : Re: Your mail to ron@vaniwaarden.org

This email address is being phased out. Please use <email address hidden> in the future.

--Ron

12 comments hidden view all 115 comments
Revision history for this message
Peter (peter-zuesli) wrote :

I had absolutely the same issue as you describe. My device is the iGotU GT600.

But it happened in "myTracks 3.0.1" (OSX El Capitan) and not in "igotu2px". If myTracks uses igotu2px then it makes sense, but if not, then its a problem of the device itself?

As a software developer I don't understand why the code should jump from 2015 to 2000. Is there any solution intended?

For the moment I fixed it by exporting a GPX file and then replacing the wrong year in a text editor, before importing the GPX file into Lightroom. Not quite elegant, but it works.

By the way: How do you delete the tracks from your GT120? The software "myTracks" can't do it and I don't want to buy a Windows PC, just for being able to delete all tracks.

I am very happy with the "old" GT600 and would not like to buy another brand, just because the software does not work properly.

Regards,
Peter

Revision history for this message
Daniel (hackie) wrote :

@Peter: igotu2gpx has "Clear Memory" toolbar button and menu item. In fact, the tool is what a linux user expects: compact, easy to use and feature complete - in contrast to the original software which is 70MB+, slow, complicated and sometimes doesn't find the device.

I't just a theory, but I believe the device has only 4 bits for the year, to which the client adds 2000. 4 bits = 0x0f = 0..15, so it supports years 2000..2015 and then it has an overflow and 2016 is 2000+(16 & 0x0f) which is 2000 again...

but funny because the input for this timestamp is the gps satellite data and gps itself doesn't have this issue

1 comments hidden view all 115 comments
Revision history for this message
Ronald Van Iwaarden (ron-vaniwaarden) wrote :

This email address is being phased out. Please use <email address hidden> in the future.

--Ron

Revision history for this message
Daniel (hackie) wrote :

PS: I'm sure 2017 will export as 2001 etc. and 2032 will be 2000 again.

84 comments hidden view all 115 comments
Revision history for this message
Xanax (4004uw) wrote :

My mod: in igotupoints.cpp. (this works with old .raw files also in range 2008 to 2015) Do mod, compile, install.
And sorry for my bad English.

    if ( ((date >> 20) & 0xf) < 8)
    {
        return QDateTime
            (QDate(2016 + ((date >> 20) & 0xf), (date >> 16) & 0xf,
                   (date >> 11) & 0x1f),
             QTime((date >> 6) & 0x1f, date & 0x3f, sec / 1000, sec % 1000),
             Qt::UTC);
    }
    else
    {
    return QDateTime
        (QDate(2000 + ((date >> 20) & 0xf), (date >> 16) & 0xf,
               (date >> 11) & 0x1f),
         QTime((date >> 6) & 0x1f, date & 0x3f, sec / 1000, sec % 1000),
         Qt::UTC);
    }

Revision history for this message
Daniel (hackie) wrote :

I believe it's wrong to fix the bug in a way which lets the same error popping up again in 16 years.

I would write something like this:

    return QDateTime(
        QDate(
          ((QDate::currentDate().year() + 4 - ((date >> 20) & 0xf)) & 0xfff0) + ((date >> 20) & 0xf),
          (date >> 16) & 0xf,
          (date >> 11) & 0x1f),
        QTime((date >> 6) & 0x1f, date & 0x3f, sec / 1000, sec % 1000),
        Qt::UTC);

(didn't compile this snippet)

It will always calculate the GPS year relative to the current system date, 12 years to the past and 4 years to the future. In other words: 0 will be interpreted as 2016 in the years 2012..2027. When run in 2028 (and his GPS is still alive) it will be interpreted as 2032 etc.

Revision history for this message
Daniel (hackie) wrote :

@Benjamin, your branch is still broken...

Revision history for this message
Mawen Zi (mawenzi) wrote :

Hi,
one more information for better searching this problem on the internet (maybe some people are not able to found this issue)
- When I tried to downloaded data from i-gotu gt 600 via @atrip, I got error: No data is found in device
- I tried to find this problem according to error message, but I was unsuccesfull

- new @trip software solved my problem

Revision history for this message
Daniel (hackie) wrote :

I did the patch myself and also migrated version 0.4 from Qt4 to Qt5, necessary for installing on 16.04: https://launchpad.net/~hackie/+archive/ubuntu/igotu2gpx-ppa https://code.launchpad.net/~hackie/igotu2gpx/0.4+y2016+qt5. I'm happy for every feedback, it's my first "launchpad code".

There are some known issues which i don't know if I introduced them:
- It's not possible to step through a track, doubleclicking on a track always point to the first waypoint
- Save single track or multiple tracks by context menu is not possible but using normal menu it works
- Track download doesn't show any progress
- Closing the application doesn't work using the X button but it works using the normal menu
- Multiple warnings on console like "Unable to find public signal for worker signal"

Most of them are probably easy to fix with some basic Qt knowledge which I don't have.

Revision history for this message
Benjamin (bben-pub) wrote :

Hello,
I'm sorry, I never got the notifications for that thread... What did not work with my branch? I'm using it for a year without problem. However, I don't have linux so I didn't recompile the debian packages, that might be your issue. It's also ossible that I failed to commit, I'm not familiar with bzr.

Best regards,
Benjamin

Revision history for this message
Daniel (hackie) wrote :

As said in #67: the branch lp:~bben-pub/igotu2gpx/fix_2016 contains as latest change "212. By charles <charles@masterpingoo> on 2011-01-15" which is far before you started to change codes for this bug. You might have branched the wrong thing or forgotten to push

Revision history for this message
Benjamin (bben-pub) wrote :

Indeed, the right branch is lp:~bben-pub/igotu2gpx/igotu2gpx
Sorry for the confusion...
By the way, I made a different interpretation than you on the handling of the date, as I don't consider future years as valid.

Revision history for this message
Daniel (hackie) wrote :

Personally, I prefer my solution, but it's more important that we have a "new" official version again. How about an up-to-date build? I'm afraid there's no way to skip the Qt migration (and mine doesn't work properly, maybe because I branched the wrong commit)...

Revision history for this message
Benjamin (bben-pub) wrote :

Yes, I agree that we should have an up-to-date build. Do you actually use the GUI? I only use the command line, which works perfectly fine.
And as it seems that the repo is dead, maybe it would be worth migrating it to github? I'm not familiar with bzr.
I have a mac, I can produce dmg for it.

Revision history for this message
Daniel (hackie) wrote :

Indeed I only use the GUI for saving all Track to separate files, which is not even possible without glicking on each track individually and saving it. The last time I tried the CLI tool was far before "production readiness", later I got stuck with the gui tool. Using the CLI tool would perfectly integrate into my photo workflow but the GUI is also important for the full project. Maybe it's a good idea to separate the binaries to different build targets and different .deb files so that it's possible to install the CLI without the GUI.

I also don't like bzw but it seems to be Ubuntus default for some reason. GitHub is also fine

Matija Nalis (mnalis)
Changed in igotu2gpx:
status: New → Confirmed
Revision history for this message
Matija Nalis (mnalis) wrote :

Benjamin's patch from for 2016 from http://bazaar.launchpad.net/~bben-pub/igotu2gpx/igotu2gpx/revision/213 doesn't work for me, as it breaks on GT-200

(Firmware version: 2.11, Model: GT-200) claiming to have "Number of points: 7536640" on empty device which is way too much (and so download takes hours). Without patch it correctly says "Number of points: 0"

Revision history for this message
Matija Nalis (mnalis) wrote :

daniel's patch from http://bazaar.launchpad.net/~hackie/igotu2gpx/0.4+y2016+qt5/revision/228 fixes "year 2016" issue for me without such side effects, so I've added it to my master revision at https://github.com/mnalis/igotu2gpx for Debian igotu2gpx version.

Displaying first 40 and last 40 comments. View all 115 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.