Time zones (again)

[Thiago Macieira]

On terça-feira, 21 de junho de 2016 10:26:50 PDT Linus Torvalds wrote:
> On Tue, Jun 21, 2016 at 9:08 AM, Thiago Macieira <thiago at macieira.org> 
wrote:
> > That function is totally busted, as you've noticed. Not fixing is a
> > discouragement, forcing people to find better alternatives.
> 
> Quite frankly, not fixing it is just stupid. It doesn't force people
> to find better alternatives, it just *annoys* people.
> 
> Please just add another signature for the function that does
> 
>    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.

I can add an __attribute__((deprecated)) with info on which function to use.

> instead of the current clearly broken mess.
> 
> Or add a new
> 
>     fromSecsSinceEpoch()

That I can easily do. We have addSecs() anyway, so why not that?

> helper or something. Because "msecs" isn't really a sane format. It's
> not something you get from *anything* else. Even when you are 64-bit
> clean (perhaps exactly because you know your target is 64-bit),
> nothing sane returns msecs.

poll(2) and many other API uses milliseconds, including a lot of Win32 API 
(notably, WaitForSingleObject) and all of the Qt timeout-related API. We need 
consistency with ourselves at least. (the only exception to the rule is 
QThread::wait(), which takes a ulong, instead of qint64)

As a twist of irony, since Qt 5.7, provided that the Glib integration is not 
active, Qt uses ppoll(2) on Linux and similar API on the BSDs, which take a 
timespec parameter.

> So forcing those idiotic multiplications by 1000 is not "finding a
> better alternative". It's just crazy crap, and makes the Qt date
> handling look incompetent. Which it is. Because "time_t" really is not
> "unsigned int", and has never EVER been that.

If you don't want to multiply and divide by 1000, use milliseconds, since 
that's what QTime and QDateTime store internally. If I add the 
fromSecsSinceEpoch() and toSecsSinceEpoch(), that's what they'll be doing.

The upcoming trend I see outside of Qt is to store things as nanoseconds, even 
though 2^63 ns is only 292.2 years. I much prefer timespec, since it gives me 
94 bits of precision (plus sign bit).

PS: Cocoa (Apple) API uses double...
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center