Time zones (again)

[Robert Helling]

> On 21.06.2016, at 10:09, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> 
> However, not all of the time handling functions seem to always accept a time zone. So sometimes you end up having to pick another helper function than the one you'd naively prefer, just to get one that takes a timezone argument (that you can then set to Qt::UTC).
> 
> The "fromTime_t()" function was an example of such a case : ostensibly the right thing to use (converts from a time_t, which was exactly what we wanted) but doesn't take a timezone input.
> 
> Of course, "fromTime_t()" was then also completely broken in that it limited the input to an unsigned integer, which was just incredibly broken and doesn't actually match time_t at all. So the whole function was just shit. But there may be similar gotchas elsewhere.
> 
> 
That is indeed a problem. As you know, from_Timet has this signedness problem but luckily there is the millisecond version that takes a signed value. For some reason that I don’t understand, the inverse function to_MSecsSinceEpoch does not take a time zone argument. What I propose is upon initialization setTimezoneSpec once with UTC then for conversion functions there is no further need to explicitly state time zone specifications (the unsignedness problem of course remains unless we use the millisecond version everywhere).

Best
Robert

--
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                      Scientific Coordinator
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160621/beae80ad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160621/beae80ad/attachment-0001.sig>