On 27 April 2015 at 21:17, Christian Mollekopf <chrig...@fastmail.fm> wrote:
> 1. add isDateOnly functionality to QDateTime ... > Opinions following: > 1. I'm not sure whether it semantically makes sense to have a QDateTime > without a time. Adding it to QDateTime was not an option Thiago was happy with so it didn't make it, It is something only used inside PIM so there's no wide use-case for it. I do think I could add it fairly easily as a new internal attribute flag, but it could complicate the code a lot and I'm also not sure it's possible to do with a backwards compatible behaviour either. Using a QDate in the api is probably not an option for PIM though as it doesn't have a QTimeZone attached which you will certainly always need (and yes, that is a reason for doing it in QDateTime). One option is the invalid QTime that Aleix mentions. I did have that in the back of my mind while re-writing QDateTime internals and so whatever QDate, Qtime and QTimeZone you set should persist in spite of the QDateTIme overall being invalid. However it's not really a solution as how would you know when it was really invalid or when it was Date Only? Personally, I suspect relying on the QDateTime to tell you it is Date Only is perhaps the wrong approach? Perhaps it's actually an attribute of the Event that it is Date Only and not an attribute of the QDateTime? Rather than checking the QDateTime you've received from a call to start() to see if it is Date Only, you should be checking if the Event itself is Date Only? Your setter could have an enum for choosing, or separate setters for QDate and QDateTime, and then have a getter for QDateTIme and another for the enum. While this may seem like a little more work for PIM, it's not used in many places so I think this may be a better option, and easier to achieve too in the required timeframe as it's all in your own control. > It would make sense to have a PointInTime with higher or > lower accuracy though. I had pondered for a while having that, but with QDateTime internals now entirely held as milliseconds relative to the Unix epoch and translated into the QDate and QTime relative to the QTimeZone on the fly, that's effectively what QDateTime has become. Now, a QDuration class, or duration mode for QDateTime, could be useful though... Cheers! John.