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…
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 ?
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.
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.