Time zones (again)

[Linus Torvalds]

On Tue, Jun 21, 2016 at 11:22 AM, Thiago Macieira <thiago at macieira.org> wrote:
>>
>>    fromTime_t(qint64, const QTimeZone);
>
> I can add that, but I can't add a qint64 toTime_t(), as you can't overload on
> return value. So it would only be a half solution.

Can you at least make sure that the return value of "toTime_t" is
actually a "time_t".

Because seriously, the fix for 32-bit architectures is to make
"time_t" be 64-bit even there in user space. We already have most of
the system calls, so it's going to be about libc issues just switching
over to a 64-bit time_t.

So having "uint32_t" for *aything* that talks about "time_t" is very
very wrong today (on 64-bit platforms), and it's only going to be even
more wrong tomorrow (because it's going to be wrong even on 32-bit
platforms).

So quite frankly, this is all just unacceptable SHIT:

    uint toTime_t() const;
    void setTime_t(uint secsSince1Jan1970UTC);
    static QDateTime fromTime_t(uint secsSince1Jan1970UTC);
    static QDateTime fromTime_t(uint secsSince1Jan1970UTC, Qt::TimeSpec spec,
                                int offsetFromUtc = 0);
    static QDateTime fromTime_t(uint secsSince1Jan1970UTC, const
QTimeZone &timeZone);

and anybody who thinks that "time_t" is deprecated just doesn't know reality.

"uint" is wrong. It was wrong yesterday, it's wrong today, and it will
be increasingly wrong tomorrow.

And no, the answer really isn't "don't use time_t". Because time_t is
all we will ever have. If anybody told you that time_t is going away,
they were insane and badly informed.

              Linus