What is the Ticks property in DateTime doing ?

I did


in a toffee and island console apps

2022-07-02 23:12:01.998631-0400 TicksIslandConsoleApplication[64132:20920022] 637924147210009982
2022-07-02 23:13:35.048382-0400 TicksToffeeConsoleApplication[64380:20922836] 637924004150464900

For a minute and a 1/2 difference the values seem to be way off in the Toffee version


Hmm, indeed. Thuis seems wring:

    property Ticks: Int64 read
      {$ELSEIF TOFFEE}Int64((mapped.timeIntervalSince1970 + NSTimeZone.localTimeZone.secondsFromGMTForDate(mapped)) * TimeSpan.TicksPerSecond) + TicksTill1970

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?


      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?

If I im building with the external compiler, to test I just need to copy the .a and .fx files to wherever I have my zip distro installed ?

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)

The toffee ticks constructor compensated for the ticks property.

I think this extra change works

Thanx! in for the next build.

With Toffee

var dateTime := new DateTime(new DateTime(1970,1,1).Ticks);

Results in

1970-01-01 05:00:00 +0000

(RTL2/DateTime.pas at master · remobjects/RTL2 · GitHub)

Should this code just be ignoring CurrentCalendar and creating one with a GMT timezone instead ?


Mind you there are other places where currentcalendar is used

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:

Island does the same.

I thought that all dates in RTL2 would be utc

This part is fixed and in.

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.

Thats an island console app isnt it ?

I get

The magic happens here.
7/6/2022 8:42:39 a 0
7/6/2022 12:42:39 a 0
7/6/2022 8:34:00 a 0

Is that because Im in Canada ?

Im referring to the a 0 and not the time :slight_smile:

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.

Is there a reason the Island DateTime has utcnow and now but the RTL DateTime only has utcnow ?

To discourage use of non-UTC dates :wink:

ok :slight_smile:

I tried the latest and without using the timezone I get differences between darwin and toffee when using rtl2.

Can you elaborate? You mean with UtcNow?

No the behavior of the constructor

var dateTime := new DateTime(new DateTime(1970,1,1).Ticks);

I have some code which is doing something like

DateTime.UtcNow - new DateTime(1970,1,1)

It behaves differently in Toffee and Darwin

That is with or without your fix? I’ll check.