Ugh.  Yes, that was new in Qt 4.7.

Zingo, what is this code trying to do, anyway?  If the GPS is recording fractional seconds, why can't we just use data that without regard to "drift"?

Having already subclassed QDateTime, we could stuff something approximately like this into datetime, but let's instead see if we can just make the caller a little less odd.

  void setMSecsSinceEpoch(qint64 msecs) {
    int ddays = msecs / 86400000;
    msecs %= 86400000;
    setDate(QDate(1970, 1, 1).addDays(ddays));

On Tue, Jun 10, 2014 at 9:38 PM, tsteven4 <> wrote:
Jenkins is about to complain In function ‘void read_point(route_head*, gpsbabel::DateTime&)’: error: ‘class gpsbabel::DateTime’ has no member named ‘setMSecsSinceEpoch’

This is a Qt4 thing we have worked around in the past.

On 6/10/2014 8:14 PM, Robert Lipe wrote:
Lovely.  I did make one change for time zone handling that I'd like to you double-check, but I've committed it so we can iterate on it from here.  I changed the reference file to match this change...which means I've just unplugged the smoke detectors if my interpretation that the device data is actually in UTC was wrong.

The copyright thing really isn't meant to be a sticking point.  Obviously, I'm not interested in "coming after" you for your own work nor do I have any interest in scouring the planet for copyrighted occurrences of "int i = 0;" - that's very much the point of BEING open source.

What I DO have a problem with is companies taking GPSBabel's guts - even down to typos we've made - changing the name, removing all the copyright/licening info, sticking it in a "product"  that's often little more than a batch file and selling it for $20-$300 dollars.  (None of this is a fictitious example.)  When I have to send cease and desist orders, I'm in a stronger position to do so if we have ONE license and I'm a copyright holder or at least co-owner.  All the formats and filters are "derived works" from ours, so I like the notices to show that.

This kind of thing does have tangible benefits.  Several times in GPSBabel history when we've found companies using GPSBabel while stripping the license info we've found it's an oversight and they fix it.  Similarly, we've had companies shipping "enhanced" versions of GPSBabel that didn't understand the license and in almost every case, they've wound up contributing the work into the project.  So the GPL is working as intended in that way - the whole idea is to MAKE everyone share.

So let's figure out the timezone thing and wrap it up.  Thanx!

On Tue, Jun 10, 2014 at 5:23 PM, Zingo Andersen <> wrote:

Thanks for your time, 
I think I manage to fix all you comments, let me know if you have some remaining comments on this version.

(Added some comments inline below, but its probably mostly me just thinking out loud, no need to comment back)

2014-06-10 4:24 GMT+02:00 Robert Lipe <>:
Hi, and welcome!

This looks pretty good!  A few minor nits.

Please use GPL2.  As this is a derived work of ours, I'm able to defend our legal position better if the license isn't diluted with multiple licenses and if I'm at least one of the owners of the code.

I kind of like that people could get inspired with the code whatever project licences they are using but I understand your position and there is not a big clash, so Ill changed it (had the same policy on my own open source project way back when I was active in it).

Also I kind of don't like rewriting all the structs again if I add support in other project (with other licenses) they would become "stupidly" equal and one could claim that they are coped from this project anyway. But I still have the first patch with PD and my (c) so I can work from that version and copy&paste the structs If I need (and change the license on the new code).
Instead of a verbose flag, please use global_opts.debug_level.

Don't torture yourself with struct tm; use the native Qt Date/Time/DateTime facilities.  That'll get you sub-second support, too, which it looks like you're computing and then dropping ont he floor.  You can construct a QDate(year, month, date) directly from workoutDateStart.

Thanks!!  The code got more readable/maintainable but I kind of don't like all the coping of time/date objects, would be nice if the addMSec() just added to the object and not returned a new object, but not mutch to do about it and speed/memory is not such a big deal anymore (and I need a version without msec anyway, and keeping it on the stack is quite cheep)
Since this isn't a serial device, there's no real reason to use masked_object; just read anything you can find int he file.

Aaa, I now understand why it's there. Thanks for the heads up. 
Please pump up the doc a little bit with a list of supported devices and clues on how to get the files from the devices and other things that users would like to know.

Added some more text.
Thanx for taking this on.  it's not far at all from being committable.

On Mon, Jun 9, 2014 at 1:13 AM, Zingo Andersen <> wrote:
Here is my first attempt to add support for Energympro training watches ( ) to gpsbabel.  
As I understand this is the way to ask/supply for contribute.

The patch contains a binary file that "svn diff" didn't supply, this file is attached on the side here (energygympro.cpo) and should go to reference/track/ 

​Ill assume the patch probably needs some fixing so just let me know what to fix and Ill rework/reapply it until all parts are happy.

Thanks for your project and your time with this, take care and happy hacking. 
/ Zingo

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration

Gpsbabel-code mailing list