it’s both, see https://docs.elementscompiler.com/Platforms/Cocoa/LegacyCocoaMode/
curious though, NSTimeZone.localTimeZone is fine, and
class property LocalTimezone: NSTimeZone := NSTimeZone.localTimeZone;
...
{$ELSEIF TOFFEE}Int64((mapped.timeIntervalSince1970 + DateTimeHelpers.LocalTimezone.secondsFromGMTForDate(mapped)) * TimeSpan.TicksPerSecond) + TicksTill1970
seem straight-forward enough…
Thanks, logged as bugs://84611
Freaky, I cant repro the issue with a locally build copy of RTL2 and I now cant repro it with the shipping version anymore either…
With this one , I was looking at the change in the debugger. Im not sure it looks correct ? The year for now2 is -9837
Also, would it be possible to document what ticks is meant to represent ?
bugs://84611 got closed with status fixed.
This still doesnt work.
If I ssh into the pi and do a date I get
Sat 11 Jul 00:44:38 UTC 2020
The code is doing this
var ts: rtl.__struct_timespec;
rtl.timespec_get(@ts, rtl.TIME_UTC);
var now := new DateTime((ts.tv_sec * RemObjects.Elements.System.DateTime.TicksPerSecond) + (ts.tv_nsec / 100000));
It looks like the value in ts.tv_sec is so big that it overflows int64 when it does the multiplication.
bugs://84611 got reopened.
I’ll check in the raspberry pi, on linux x64 is working fine.
Is this one still being looked into ?
If it hasn’t been closed, it’s still own the lost to be looked at, yes.
bugs://84611 got closed with status fixed.
bugs://84598 got closed with status fixed.