if I drop the +NSTimeZone.localTimeZone.secondsFromGMTForDate(mapped), the value seems to be more close to what I get in Island and .NET, does that one look correct for you too?
ie
var n := DateTime.UtcNow;
var x := Int64(((n as NSDate).timeIntervalSince1970 + NSTimeZone.localTimeZone.secondsFromGMTForDate(n)) * TimeSpan.TicksPerSecond) + DateTime.TicksTill1970;
writeLn($"x {x}"); // bad
var y := Int64(((n as NSDate).timeIntervalSince1970) * TimeSpan.TicksPerSecond) + DateTime.TicksTill1970;
writeLn($"y {y}"); // correct?
That, or just drag your own copy of the .fx into the project to add a hint path and delete the original .a. from the References folder of your install (the last part because Appleās ld linker is quirky and otherwise still finds the wrong one if youāre unlucky)
TBH Iām not sure right now, both with regard to what the expectation should be for its constructor (surely a local time, not UTC?), and what the other platforms doā¦ Iāll need to review this.
Update: Microsoftās docs say that on .NET this uses the gregorian calendar always (so that part of the fix is probably good), but it doesnāt mention time zones :(. Iāll have to test.
Update 2: This seems to indicate .NET, at least, does not use GMT but the current time zone for this constructor. so that part of your fix would be bad:
I donāt believe soā¦ Thatās really not possible, as DateTime does just wrap the system types, so nothing prevents you from assigning a non-UTC System.DateTime (which iirc does store an explicit time zone, no) to an RTL2 DateTime reference.
But I agree this probably needs more review for cleanness and consistency, in general.
Above screenshot is .NET. Island gets the same result value-wise (8, 12, 8).
I too get the āa 0ā on Island (which oddly you didnāt have/mention in your other thread?). Iām not sure where that comes from, but I logged a separate issue (E25984) for that.
it looks like weāre in the same time zone ;).
Update: Locale.Current.DateTimeFormat.LongTimePattern shows āh:mm:ss a zā for me. So that probably explains it, itās probably a bug in InternalToString or GetNextFormatToken.
It looks like āaā isnāt handled at all. āzā is the offset from GMT, and it seems thatās set wrong/no timezone is provided.