Open tsteven4 opened 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: @.***>
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: @.***>
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.