Solved Get the correct date days passed after current date

I faced with interesting problem
I'm trying to calculate days diff between current date and previous savedHere is code QDateTime oNow = QDateTime::currentDateTime(); QDateTime prev = oNow.addDays(50); // Can't use daysTo() here because it counts how many 'midnights' there are between the two dates qreal oTimeUnitsBefore = oNow.secsTo(prev) / (3600 * 24);
Result will be 49, because DST used.
Any thoughts how can I get a correct value?

@Holiday
Hi. I don't know what it is you actually wish to calculate. I don't know what you mean by "days"?! Once you deal in local times and Daylight hour changes the meaning of "day" becomes ambiguous. There are two obvious definitions for "day" (there are others, connected with the sun or The Universe!): 24 hours
 The time/number of hours between a (local) wallclock timeofday one day and the same wallclock timeofday on another day.
The first, 24 hours, is nice and easy! The second is not: one "day" per year has 23 hours, another has 25 hours, one day per year has two "2:30AM" wallclock times and another day per year has no "2:30AM" wall clock time at all!
You can only safely use the
3600 * 24
when you are talking about UTC, where every day has 24 hours. And that is what @mrjj's code is using. If you convert your local times to UTC and use that 24 hour division we know where we are.If you want to use local times and allow the two dates to cross daylight saving boundaries I think you have to be very exact about what answer you are expecting/wanting.

@Holiday said in Get the correct date days passed after current date:
qreal oTimeUnitsBefore = oNow.secsTo(prev) / (3600 * 24);
==> this is wrong, you are dividing integer with integer, so the result will be an integer.
If you want result to be a qreal, you should do:
qreal oTimeUnitsBefore = oNow.secsTo(prev) / (3600 * 24.0);

Thanks for pointing that. But that's not the root cause and won't fix my problem

@Holiday said in Get the correct date days passed after current date:
Thanks for pointing that. But that's not the root cause and won't fix my problem
So I don't understand what your problem is.
My understanding was you've got 49, but you expected 50 days.
I am pretty sure
qRound(oNow.secsTo(prev) / (3600 * 24.0))
will return 50. 
qRound yes, as it round value.
Ok, let's change this example to excape qreal value.
QDateTime zx = QDateTime::currentDateTime(); QDateTime cvb = oNow.addDays(50); int val = cvb.secsTo(zx) / (3600 * 24);
As I set up 50 days, I'm expecting, that val will be 50, but due DST I receiving 49, because I got 50 days in seconds  2 hour (DST change)
P.S. And thanks for helping me with that

Hi
So you want the class to ignore DST ?
https://doc.qt.io/qt5/qt.html#TimeSpecenum
("Neither UTC nor OffsetFromUTC has any transitions.")QDateTime oNow = QDateTime::currentDateTimeUtc(); QDateTime cvb = oNow.addDays(50); qint64 v1 = cvb.secsTo(oNow); qreal v2 = (3600 * 24); qreal v3 = v1 / v2; qDebug() << v1 << "/" << v2 << "=" << v3;
4320000 / 86400 = 50
ps. Not sure this is what you want :)

@mrjj Thanks, that's work!
But what if cvb will be the LocalTime value (as it reads from file from as string and converts to QDateTime with QDateTime::fromString() funct)? ToUtc() doesn't help in this caseauto withTZ = QDateTime::currentDateTime(); auto current = QDateTime::currentDateTimeUtc(); QDateTime prev = withTZ.addDays(50); qint64 v1 = prev.toUTC().secsTo(current); qreal v2 = (3600 * 24); qreal v3 = v1 / v2; qDebug() << v1 << "/" << v2 << "=" << v3;

@Holiday
Hi. I don't know what it is you actually wish to calculate. I don't know what you mean by "days"?! Once you deal in local times and Daylight hour changes the meaning of "day" becomes ambiguous. There are two obvious definitions for "day" (there are others, connected with the sun or The Universe!): 24 hours
 The time/number of hours between a (local) wallclock timeofday one day and the same wallclock timeofday on another day.
The first, 24 hours, is nice and easy! The second is not: one "day" per year has 23 hours, another has 25 hours, one day per year has two "2:30AM" wallclock times and another day per year has no "2:30AM" wall clock time at all!
You can only safely use the
3600 * 24
when you are talking about UTC, where every day has 24 hours. And that is what @mrjj's code is using. If you convert your local times to UTC and use that 24 hour division we know where we are.If you want to use local times and allow the two dates to cross daylight saving boundaries I think you have to be very exact about what answer you are expecting/wanting.

@JonB
Thanks for help. Yes, the main question in my problem was: what we mean by "days". 24 hour or days between midnight. When I found an answer on this question, I found a solution.
Huge thanks everyone for help!