Am 21.09.2019 um 00:12 schrieb Thiago Macieira:
On Friday, 20 September 2019 14:20:40 PDT Patrick Stinson wrote:
QDateTime initializes with a different time zone offset when passed a QDate
before versus after Jan 1 1970. The following line says it all:
QDateTime(QDate(1969, 10, 14)).offsetFromU
TableView.forceLayout() seems prone to throwing assertions related to internal
data structures being out of sync with the number of rows and columns from the
QAbstractTableModel used. Some of these assertions were fixed in 5.13.0, more
were fixed in 5.13.1. But this one still remains:
items/qqu
I received this error after upgrading from 5.13.0 to 5.13.1 and disconnecting
my external monitor from my latest-model MacBook with Mojave:
qcocoascreen.mm:557:None(): ASSERT failure in QCocoaScreen: "The application's
primary screen should always be in sync with the main display", file
qcocoas
On Friday, 20 September 2019 14:20:40 PDT Patrick Stinson wrote:
> QDateTime initializes with a different time zone offset when passed a QDate
> before versus after Jan 1 1970. The following line says it all:
>
> QDateTime(QDate(1969, 10, 14)).offsetFromUtc() != QDateTime(QDate(1970, 10,
> 14)).of
QDateTime initializes with a different time zone offset when passed a QDate
before versus after Jan 1 1970. The following line says it all:
QDateTime(QDate(1969, 10, 14)).offsetFromUtc() != QDateTime(QDate(1970, 10,
14)).offsetFromUtc()
It seems to me that the offsets for these two QDateTime ob