On quinta-feira, 28 de abril de 2016 16:17:15 PDT Linus Torvalds wrote: > That's very odd. It's *especially* odd since I'm doing this on x86-64, > which natively has a 64-bit signed time_t, and all the normal date > handling functions should just work fine. But Qt seems to have explicitly > screwed up here. > > Thiago?
Historical raisins... In order to support multiple operating systems with dubious definitions of time_t (signed, unsigned, 32-bit, 64-bit), the API was crystallised on unsigned some time in the past. I'd advise against using this function that you found: > Looking at > > http://doc.qt.io/qt-5/qdatetime.html#fromTime_t-1 > > it just looks like "QDateTime::fromTime_t()" is completely and utterly > broken. Yep. But we have to carry it for compatibility. > I guess we could replace all those with > > QDateTime::fromMSecsSinceEpoch(when*1000, Qt::UTC) > > or something. I have *not* tested whether that works. That's what I recommend. The range is ± ~292 million years . It's also 64-bit even on 32-bit systems with time_t definitions unsafe after 2038. Which means you've got +1 from me on your second patch. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface