GPSBabel / gpsbabel

GPSBabel: convert, manipulate, and transfer data from GPS programs or GPS receivers. Open Source and supported on MacOS, Windows, Linux, and more. Pointy clicky GUI or a command line version...
https://www.gpsbabel.org
GNU General Public License v2.0
451 stars 123 forks source link

strftime/strptime specifiers -> QDate/QTime/QDateTime specifiers? #1113

Open tsteven4 opened 1 year ago

tsteven4 commented 1 year ago

We have lamented publishing the strftime/strptime specifiers. We could replace these by QDate/QTime/QDateTime specifiers. I note the toString versions are independently documented with some variances.

Would we just be jumping from one lament to another?

Potentially it would allow us to get rid of strptime/strftime/. I think conversion of the remaining xcsv styles would be easy. I think google wouldn't even give a seconds thought to interface stability while sun would agonize over it until bankruptcy.

robertlipe commented 1 year ago

Maybe. I have my eye on a time when QDateTime becomes std::chrono, but that might happen right before Sun's re-emergence and subsequent re-bankruptcy.

In theory, there are style files in the world that aren't in our tree. Don't know how common that really is.

Somewhere fairly recently, I wrote a shim that took a strtime (strptime?) string and made it into a QT timespec. Maybe it was the other way around. There were lots of things it didn't handle, but it was another Paretto case where doing 20% of the specifiers got us (more than) the 80% we needed. It's a pretty mechanical transformation for the simple cases.

NOte that we actually have terrible test coverage of the *.style file formats.

In Google-land, those *.style formats would be a (versioned) protobuf. You're not wrong about your analogy. Google tooled for that kind of thing very early.

On Sun, May 14, 2023 at 8:28 PM tsteven4 @.***> wrote:

We have lamented publishing the strftime/strptime specifiers. We could replace these by QDate https://doc.qt.io/qt-6/qdate.html#fromString/ QTime https://doc.qt.io/qt-6/qtime.html#fromString/QDateTime https://doc.qt.io/qt-6/qdatetime.html#fromString specifiers. I note the toString versions are independently documented with some variances.

Would we just be jumping from one lament to another?

Potentially it would allow us to get rid of strptime/strftime/. I think conversion of the remaining xcsv styles would be easy. I think google wouldn't even give a seconds thought to interface stability while sun would agonize over it until bankruptcy.

— Reply to this email directly, view it on GitHub https://github.com/GPSBabel/gpsbabel/issues/1113, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD356OGH32QMXT3AYUFDXGGBCXANCNFSM6AAAAAAYBQM4NU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

robertlipe commented 1 year ago

Aha. garmin_txt.cc:strftime_to_timespec

It let me delete something in garmin_txt what was a pain point, IIRC. Odd, since the guts of that format are not my favorite code and I know it was on the chopping block.

On Sun, May 14, 2023 at 10:08 PM Robert Lipe @.***> wrote:

Maybe. I have my eye on a time when QDateTime becomes std::chrono, but that might happen right before Sun's re-emergence and subsequent re-bankruptcy.

In theory, there are style files in the world that aren't in our tree. Don't know how common that really is.

Somewhere fairly recently, I wrote a shim that took a strtime (strptime?) string and made it into a QT timespec. Maybe it was the other way around. There were lots of things it didn't handle, but it was another Paretto case where doing 20% of the specifiers got us (more than) the 80% we needed. It's a pretty mechanical transformation for the simple cases.

NOte that we actually have terrible test coverage of the *.style file formats.

In Google-land, those *.style formats would be a (versioned) protobuf. You're not wrong about your analogy. Google tooled for that kind of thing very early.

On Sun, May 14, 2023 at 8:28 PM tsteven4 @.***> wrote:

We have lamented publishing the strftime/strptime specifiers. We could replace these by QDate https://doc.qt.io/qt-6/qdate.html#fromString/ QTime https://doc.qt.io/qt-6/qtime.html#fromString/QDateTime https://doc.qt.io/qt-6/qdatetime.html#fromString specifiers. I note the toString versions are independently documented with some variances.

Would we just be jumping from one lament to another?

Potentially it would allow us to get rid of strptime/strftime/. I think conversion of the remaining xcsv styles would be easy. I think google wouldn't even give a seconds thought to interface stability while sun would agonize over it until bankruptcy.

— Reply to this email directly, view it on GitHub https://github.com/GPSBabel/gpsbabel/issues/1113, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD356OGH32QMXT3AYUFDXGGBCXANCNFSM6AAAAAAYBQM4NU . You are receiving this because you are subscribed to this thread.Message ID: @.***>