[Development] Adding more Datetime classes to Qt

[Edward Welbourne]

Mark De Wit (10 April 2019 12:36) wrote:
> It might be good to highlight, for instance, that MSecsSinceEpoch is
> not share-able between users in different timezones unless QDateTime
> is instantiated with a timespec of Qt::UTC (which is not the default).

In what sense can't "milliseconds since epoch" values be shared ?
Note that they're always time since 1970-01-01 00:00 UTC, regardless of
which time-spec your QDateTime is using.

(If you dig the milliseconds from epoch value out of the guts of a
QDateTime, that's related to an origin with the same offset from UTC as
the QDateTime's spec currently uses; but you shouldn't be doing that.
Use QDateTime's methods; {to,from}MSecsSinceEpoch(), which both refer to
the UTC epoch.)

> The defaults (local time w. timezone conversion) are perhaps more
> likely to lead to error than the plain C time since epoch with no
> hours being added/subtracted.

The "plain C time since epoch" is also referred to UTC, so (aside from a
factor of 1000) is no better or worse than our "milliseconds since
epoch" (aside from the range of date-times expressible being narrower,
for a given integral type; but we use a 64-bit type, which leaves an
acceptably wide range).

We're stuck with the defaults we have (thanks to binary and source
compatibility promises), but you can over-ride them easily enough.  Just
pass Qt::UTC as third argument to the QDateTime constructor and you've
got what you want.  Or map the QDateTime you've got through
.toTimeSpec(Qt::UTC) to put it in the standard form.  Or just ask for its
.toMSecsSinceEpoch() to reduce it to a simple number, regardless of its
spec; and you can compare these, from different-spec QDateTime values.
Then again, you can just compare the QDateTime values; they'll sort out
their difference in offset if they need to.

As for the documentation, if you can see ways to improve it, please give
us patches or file bug reports that explain clearly what's confusing
you,

	Eddy.