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

[tsteven4]

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]

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 <#1113>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD356OGH32QMXT3AYUFDXGGBCXANCNFSM6AAAAAAYBQM4NU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[robertlipe]

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 > <#1113>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCSD356OGH32QMXT3AYUFDXGGBCXANCNFSM6AAAAAAYBQM4NU> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >